Webpack --watch не компилирует измененные файлы

Ответ 1

FYI: кажется, что ОС X может иметь поврежденную папку и больше не отправлять fsevents (который используется watchpack/chokidar/Finder) для себя и для любых дочерних папок. Я не могу быть уверен, что это случилось с вами, но это было очень неприятно для меня и коллеги.

Мы смогли переименовать коррумпированную родительскую папку, а затем посмотреть события сразу же, как и ожидалось. См. Это сообщение в блоге для получения дополнительной информации: http://feedback.livereload.com/knowledgebase/articles/86239-os-x-fsevents-bug-may-prevent-monitoring-of-certai

Рекомендуемые исправления из приведенной выше ссылки:

• перезагрузка компьютера.
• проверка диска и восстановление разрешений с помощью Disk Utility
• добавление папки в список конфиденциальности Spotlight (список папок для индексирования), а затем удаление из него, эффективное принудительное переиндексирование
• переименовать папку, а затем, возможно, переименовать ее
• повторное создание папки и перенос старого содержимого обратно в нее

Первые два не работали для нас, не пробовали предложение Spotlight, и повторное создание не оказалось необходимым.

Мы смогли найти папку с корневыми проблемами, открыв Finder и создав файлы в каждой последовательной родительской папке, пока не появится сразу (поскольку Finder тоже получит эту ошибку). Недопустимый корневой каталог, который не обновляется. Мы просто mv 'd it и mv' возвращаем его к исходному имени, а затем наблюдатель работал.

Не знаю, что вызывает коррупцию, но я просто рад, что у меня есть исправление.

Ответ 2

Если ваш код не перекомпилирован, попробуйте увеличить количество наблюдателей (в Ubuntu):

echo fs.inotify.max_user_watches=524288 | sudo tee -a /etc/sysctl.conf && sudo sysctl -p

Источник: https://webpack.github.io/docs/troubleshooting.html

Ответ 3

Добавление следующего кода в файл конфигурации моего веб-пакета исправило проблему, надеюсь, это поможет. Не забывайте игнорировать папку node_modules, так как это снизит производительность для HMR (горячая замена модулей):

watchOptions: {
  poll: true,
  ignored: /node_modules/
}

Ответ 4

У меня была эта проблема при работе с WebStorm.

Отключение настроек → Настройки системы → "Безопасная запись" разрешило это для меня.

Нашел рекомендацию сделать это в: Устранение неполадок WebPack

Ответ 5

Просто добавьте к возможным решениям: У меня была папка с проектом внутри папки Dropbox, и ее решение решило проблему для меня. (OS X)

Ответ 6

Одна из проблем заключается в том, что если ваши имена путей не являются абсолютными, тогда такие вещи будут происходить. Я случайно установил resolve.root в ./ вместо __dirname, и это заставило меня тратить много времени на удаление и повторное создание файлов, подобных парням выше меня.

Ответ 7

Если изменение fs.inotify.max_user_watches, поскольку Cesar по-прежнему не работает, попытайтесь использовать опрос вместо собственных наблюдателей, создав script, как показано в docs или запуск webpack с параметрами --watch --watch-poll.

Ответ 8

Обновления: удаление всего каталога и git клонирование заново из репо исправляет мою проблему.

Ответ 9

Если вы используете Vim, попробуйте настроить backupcopy на yes, а не на авто по умолчанию. В противном случае Vim иногда переименовывает исходный файл и создает новый, который будет беспорядочно смотреть с веб-часами:

https://github.com/webpack/webpack/issues/781

Просто добавьте это в свои настройки vim, если это так:

установить backupcopy = yes

Ответ 10

Чувствительность к папке была моей проблемой. Мои вызовы кода для require() содержали все имена путей в нижнем регистре, нО фактически каталоги содержали заглавные буквы. Я переименовал все свои каталоги в строчные, и просмотр веб-пакетов сработал мгновенно.

Ответ 11

Обратите внимание, что если вы запускаете веб-пакет на виртуальной машине (Vagrant/Virtualbox) и изменяете свои файлы на платформе хоста, обновления файлов в общей папке могут не вызывать inotify в Ubuntu. Это приведет к тому, что изменения не будут приняты веб-пакетом.

см.: Виртуальный билет № 10660

В моем случае редактирование и сохранение файла на гостевой (в vi) действительно запустило веб-пакет. Редактирование его на хосте (в PhpStorm, Notepad или любом другом приложении) НЕ запускает веб-пакет, что бы я ни делал.

Я решил это с помощью vagrant-fsnotify.

Ответ 12

Работа для меня в усадьбе Laravel

--watch --watch-poll

Ответ 13

У меня была такая же проблема в файле .vue. Когда сервер перезагрузился, все работает нормально, но при следующем сохранении он больше не перекомпилировался. Проблема заключалась в пути файла импорта, в котором была заглавная буква. Очень сложно понять эту проблему, потому что все работает на перезагрузке сервера. Проверьте случай ваших путей.

Ответ 14

Он не был перекомпилирован для меня, но потом я понял/вспомнил, что веб-пакет следит за графиком зависимостей, а не только за папкой (или файлами). Конечно, файлы, которые я менял, еще не были частью этого графика.

Ответ 15

Для меня создание папок и файлов в VS Code было проблемой. Чтобы исправить это, я повторно клонировал свой репозиторий и на этот раз создал новые папки и файлы через командную строку вместо кода. Я думаю, что Код по какой-то причине портил файлы. Я видел только что обновленное приложение, так что, возможно, это новая ошибка.

Ответ 16

То, как я решил проблему, - найти ошибку капитализации в пути импорта. Папка в файловой системе имела строчную букву с нижним регистром, путь импорта - в верхнем регистре. Все скомпилировано в порядке, так что это всего лишь проблема с веб-пакетом.

Ответ 17

У меня такая же проблема. И я замечаю, что это не компиляция, потому что моя папка содержит некоторый символ (*). И использование старого плагина watcher, похоже, решает проблему. Добавьте эту строку в конфигурационный файл webpack.

plugins: [
    new webpack.OldWatchingPlugin()
  ]

Ответ 18

У меня была аналогичная проблема: ни веб-пакет, ни накопитель в режиме просмотра часов не улавливали изменения, которые я сделал. Я узнал, что это была моя ошибка, поскольку я менял модуль (файл .tsx), который еще не был импортирован нигде в приложении (например, App.ts, который является точкой входа), и я ожидал, что инструменты построения сообщают об ошибках я сделал там.

Ответ 19

Для меня удаление node_modules и выполнение npm install или node_modules заново для установки всех пакетов решило проблему

Ответ 20

Также эта проблема возникла в виртуальной машине VirtualBox (5.2.18) Ubuntu (18.04) с использованием Vagrant (2.1.15) с синхронизацией rsync. Внезапно первая сборка работает отлично, но Webpack впоследствии не учитывает изменения, даже с установленным fs.inotify.max_user_watches=524288. Добавление poll: true в конфиге Webpack тоже не помогло.

Только vagrant-notify-forwarder работал (бродяга-fsnotify не по какой - то причине), но потом перестроение произошло слишком быстро после сохранения файла на хосте, и я полагаю, что Rsync не было достаточно времени, чтобы закончить свою задачу ( возможно из-за количества синхронизированных каталогов в моем Vagrantfile?).

Наконец, я снова заставил часы работать, также увеличив aggregateTimeout в моей конфигурации Webpack:

module.exports = {
  watch: true,
  watchOptions: {
    aggregateTimeout: 10000
  },
  ...
}

Если это решение работает для вас, попробуйте снова понизить это значение, в противном случае вам придется подождать 10 секунд, пока сборка не будет перезапущена при каждом нажатии кнопки сохранения. Значение по умолчанию составляет 300 мс.

Ответ 21

Простое решение для MacOS следующее:

Откройте два окна терминала в том же каталоге, в котором находится ваш проект.

В первом окне терминала запустите: webpack --watch

Во втором окне окна терминала: webpack-dev-server

Я пробовал много возможных решений, и это кажется самым надежным

Ответ 22

Возможное решение: изменение контекста в каталоге приложения.

У меня были все мои файлы конфигурации webpack в подпапке:

components/
webpack/
 development.js
app.js

В webpack/development.js, установите context: path.join(__dirname, '../'), решив мою проблему.

Ответ 23

Попробовав несколько стратегий для исправления этой проблемы, я закончил тем, что просто сдался, но затем, решая еще одну проблему, я снова попытался, и внезапно флаг --watch наконец-то работал.

Честно говоря, я не знаю, что конкретно заставило его работать, но после выполнения следующих шагов он только начал работать:

1. Install most recent gcc version
$ sudo port install gcc48
$ sudo port select --set gcc mp-gcc48

2. Install most recent clang version
$ sudo port install clang-3.6
$ sudo port select --set clang mp-clang-3.6

3. Export variables holding the patch to C and C++ compiler
$ export CC=/opt/local/bin/clang
$ export CXX=/opt/local/bin/clang++

Возможно, при установке этих пакетов какая-то зависимость просто добавила недостающую часть головоломки, кто знает...

Надеюсь, что эта помощь поможет любому, кто пытается там работать.

Ответ 24

Я добавляю еще один ответ, потому что считаю, что это лучшее решение. Я использую его каждый день, и он потрясает! Просто установите эту библиотеку:

https://github.com/gajus/write-file-webpack-plugin

Описание: Заставляет программу webpack-dev-server записывать файлы пакетов в файловую систему.

Как установить:

npm install write-file-webpack-plugin --save-dev

Ответ 25

Попробуйте изменить --watch на -d --watch

работал на меня

Ответ 26

Если это произошло внезапно в вашем проекте, это может решить проблему.

Может быть, каким-то образом файлы, которые отслеживали ваш проект, изменились, которые ищет веб-пакет, были повреждены. Вы можете создать их снова, просто выполнив следующие простые действия.

1. выйди из своего проекта, реж. ($: cd..)
2. переместить ваш проект в другой каталог ($: mv {projectName} {newName})
3. перейти в новый каталог ($: cd {newName})
4. Запустите сервер и проверьте, перезагружается ли он при каждом изменении файла (в большинстве случаев это должно работать, поскольку теперь веб-пакет создает новые файлы для отслеживания изменений)
5. выйти из режиссера ($: cd..)
6. переместите его обратно к исходному имени ($: mv {newName} {projectNam}) Это сработало для меня............

Ответ 27

Я столкнулся с этим вопросом, когда у меня был похожий issue--, и оказалось, что веб-пакет не восстанавливается, даже при запуске веб-пакета --config.

Я даже удалил bundle.js, и веб-страница по-прежнему отображалась так же, как и до моих изменений.

Для тех из вас, у кого возникла такая же проблема, я, наконец, сделал опцию "пустой кэш и полная перезагрузка" в chrome (щелкните правой кнопкой мыши по кнопке перезагрузки с открытыми devtools), и это помогло.

Ответ 28

Дело в том, что webpack загружает скрипт из какого-то странного URL: webpack:///, который кешируется. Вы должны добавить версию в конец вашего скрипта, чтобы предотвратить кеширование: main-compiled.js?v=<?php echo time()?>"