webpack --watch no está compilando archivos modificados

Intenté ejecutarlo webpack --watchy después de editar mis archivos JS, no activa una recompilación automática.

Intenté reinstalar webpackusando npm uninstallpero todavía no funciona.

¿Algunas ideas?

FYI: parece que OS X puede tener una carpeta dañada y ya no enviar fsevents(que watchpack/chokidar / Finder usa) para sí mismo y las carpetas secundarias. No puedo estar seguro de que esto sea lo que te pasó, pero fue muy frustrante para mí y para un colega.

Pudimos cambiar el nombre de la carpeta principal corrupta y luego ver los eventos que se produjeron inmediatamente como se esperaba. Consulte esta publicación de blog para obtener más información: http://feedback.livereload.com/knowledgebase/articles/86239-os-x-fsevents-bug-may-prevent-monitoring-of-certai

Las correcciones recomendadas del enlace anterior son:

• reiniciar la computadora
• comprobar el disco y reparar los permisos a través de la Utilidad de Discos
• agregar la carpeta a la lista de privacidad de Spotlight (la lista de carpetas que no se indexarán), y luego eliminarla, forzando efectivamente una reindexación
• cambiar el nombre de la carpeta, y luego posiblemente cambiarle el nombre
• volver a crear la carpeta y mover el contenido antiguo a ella

Los dos primeros no funcionaron para nosotros, no probaron la sugerencia de Spotlight y la recreación no resultó necesaria.

Pudimos encontrar la carpeta raíz del problema abriendo Finder y creando archivos en cada carpeta principal sucesiva hasta que apareció una de inmediato (ya que Finder también se verá afectado por este error). La carpeta más raíz que no se actualiza es la culpable. Simplemente lo hicimos mvy mvlo devolvimos a su nombre original, y luego el observador trabajó.

No tengo idea de qué causa la corrupción, pero me alegra tener una solución.

Si su código no se vuelve a compilar, intente aumentar la cantidad de observadores (en Ubuntu):

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

Fuente: https://webpack.github.io/docs/troubleshooting.html

Agregar el siguiente código a mi archivo de configuración de paquete web solucionó el problema, espero que esto ayude. No olvide ignorar su carpeta node_modules, ya que eso mataría el rendimiento de HMR (Reemplazo de módulo en caliente):

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

He tenido este problema al trabajar con WebStorm.

Desactivar Configuración -> Configuración del sistema -> "escritura segura" lo resolvió por mí.

Encontré la recomendación para hacerlo en: Solución de problemas de WebPack

Solo para agregar a posibles soluciones: tenía la carpeta de mi proyecto dentro de una carpeta de Dropbox, moverla resolvió el problema por mí. (OS X)

La distinción entre mayúsculas y minúsculas era mi problema. Mis llamadas de código a require () tenían todos los nombres de ruta en minúsculas, PERO los directorios en realidad tenían una letra mayúscula. Cambié el nombre de todos mis directorios a minúsculas y la visualización de paquetes web funcionó al instante.

Un problema es que si los nombres de sus rutas no son absolutos, sucederán cosas como esta. Accidentalmente había configurado resolve.roota en ./lugar de __dirnamey esto me hizo perder mucho tiempo borrando y recreando archivos como los chicos de arriba.

Si cambiar fs.inotify.max_user_watches como apunta César todavía no funciona, intente usar el sondeo en lugar de los observadores nativos creando su script como se muestra en los documentos o ejecutando el paquete web con --watch --watch-pollopciones.

Tenga en cuenta que si ejecuta el paquete web dentro de una máquina virtual (Vagrant / Virtualbox) y cambia sus archivos en la plataforma de host, es posible que las actualizaciones de archivos en la carpeta compartida no activen inotify en Ubuntu. Eso hará que los cambios no sean recogidos por webpack.

ver: Boleto de Virtualbox # 10660

En mi caso, editar y guardar el archivo en el invitado (en vi) activó el paquete web. Editarlo en el host (en PhpStorm, Bloc de notas o cualquier otra aplicación) NO active el paquete web, sea lo que sea que hice.

Lo resolví usando vagrant-fsnotify .

Trabaja para mí en Laravel Homestead

--watch --watch-poll

Actualizaciones: eliminar todo el directorio y clonar git de nuevo desde el repositorio soluciona mi problema.

Si está utilizando Vim, debería intentar configurar la copia de seguridad en sí en lugar del automático predeterminado. De lo contrario, Vim a veces cambiará el nombre del archivo original y creará uno nuevo, lo que estropeará el reloj del paquete web:

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

Simplemente agregue esto a su configuración de vim si este es el caso:

establecer copia de seguridad = sí

Estaba teniendo el mismo problema en un archivo .vue. Cuando el servidor se reinició, todo funcionó bien, pero en el siguiente guardado ya no se volvió a compilar. El problema estaba en la ruta del archivo de importación que tenía una letra en mayúscula. Es muy difícil resolver este problema porque todo funciona en un reinicio del servidor. Compruebe el caso de sus caminos.

No se estaba recompilando para mí, pero luego me di cuenta / recordé que el paquete web observa el gráfico de dependencia y no solo una carpeta (o archivos). Efectivamente, los archivos que estaba cambiando aún no formaban parte de ese gráfico.

Para mí, el problema fue crear carpetas y archivos en VS Code. Para solucionarlo, volví a clonar mi repositorio y, esta vez, creé nuevas carpetas y archivos a través de la línea de comandos en lugar de Code. Creo que Code estaba corrompiendo los archivos por alguna razón. Vi la aplicación recién actualizada, así que tal vez sea un error nuevo.

Tuve un problema similar, ni el paquete web ni el paquete acumulativo en modo reloj detectaron los cambios que hice. Descubrí que era básicamente mi culpa porque estaba cambiando el módulo (archivo .tsx) que aún no se había importado en ninguna parte de la aplicación (por ejemplo, App.ts, que es el punto de entrada) y esperaba que las herramientas de compilación informaran errores. hecho allí.

La forma en que resolví el problema fue encontrar un error de capitalización en una ruta de importación. La carpeta en el sistema de archivos tenía la primera letra en minúscula, la ruta de importación estaba en mayúsculas. Todo se compiló bien, por lo que esto fue solo un problema de inclusión de reloj de paquete web.

También tuve este problema dentro de una VM VirtualBox (5.2.18) Ubuntu (18.04) usando Vagrant (2.1.15) con sincronización rsync. De repente, la primera compilación funciona muy bien, pero Webpack no tiene en cuenta los cambios posteriores, incluso con fs.inotify.max_user_watches=524288set. Añadiendopoll: true configuración de Webpack tampoco ayudó.

Solamente vagrant-notify-forwarder funcionó (vagrant-fsnotify no lo hizo, por alguna razón), pero luego la reconstrucción ocurrió demasiado rápido después de guardar el archivo en el host y supongo que rsync no tuvo suficiente tiempo para terminar su tarea (tal vez debido a la cantidad de directorios sincronizados dentro de mi Vagrantfile?).

Finalmente hice que el reloj funcionara nuevamente aumentando también aggregateTimeouten mi configuración de Webpack:

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

Si esta solución funciona para usted, intente reducir este valor nuevamente; de ​​lo contrario, tendrá que esperar 10 segundos hasta que la compilación se reinicie cada vez que presione guardar. El valor predeterminado es 300 ms .

Tengo el mismo problema. Y noto que no se está compilando porque mi carpeta contiene algún carácter (*). Y el uso del antiguo complemento de observador parece resolver el problema. Agregue esta línea a su archivo de configuración de paquete web.

plugins: [
    new webpack.OldWatchingPlugin()
  ]

Para mí, eliminar node_modulesy hacer npm install o yarn nuevamente para instalar todos los paquetes resolvió el problema

¿Cuál fue la causa en mi caso?

Parece que el valor de: max_user_watches en el /proc/sys/fs/inotify/max_user_watches webpack está afectando

Para comprobar su valor real

$cat /proc/sys/fs/inotify/max_user_watches
16384

16384 estaba en mi caso y todavía no era suficiente.

Probé diferentes tipos de soluciones como:

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

Pero parece que incluso si cambiara el valor, cuando reinicié mi PC, volvería al 16384 predeterminado.

SOLUCIÓN si tiene sistema operativo Linux (mi caso, tengo Manjaro):

Crea el archivo:

sudo nano /etc/sysctl.d/90-override.conf

Y poblarlo con:

fs.inotify.max_user_watches=200000

Parece que 200000 es suficiente para mí.

Después de crear el archivo y agregar el valor, simplemente reinicie la PC y debería estar bien.

Una solución sencilla en MacOS es la siguiente:

Abra dos ventanas de terminal en el mismo directorio donde reside su proyecto.

En la primera ventana de terminal, ejecute: webpack --watch

En la segunda terminal, ejecute Windows: webpack-dev-server

He probado muchas soluciones posibles y esta parece ser la más confiable.

Posible solución: cambiar el contexto al directorio de la aplicación.

Tenía todos los archivos de configuración de mi paquete web en una subcarpeta:

components/
webpack/
 development.js
app.js

En webpack/development.js, set context: path.join(__dirname, '../')resolvió mi problema.

Después de probar un puñado de estrategias para solucionar este problema, terminé simplemente rindiéndome, pero luego, mientras resolvía otro problema, lo intenté de nuevo y de repente el --watch bandera finalmente estaba funcionando.

Para ser honesto, no sé qué lo hizo funcionar específicamente, pero después de realizar los siguientes pasos, simplemente comenzó a funcionar:

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++

Pudo haber sucedido que al instalar estos paquetes alguna dependencia simplemente agregó la pieza faltante del rompecabezas, quién sabe ...

Espero que esto ayude a cualquiera que esté luchando para que funcione.

Estoy agregando otra respuesta porque creo que esta es la mejor solución hasta ahora. ¡Lo estoy usando todos los días y es genial! Simplemente instale esta biblioteca:

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

Descripción: Obliga al programa webpack-dev-server a escribir archivos de paquete en el sistema de archivos.

Cómo instalar :

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

Intenta cambiarte --watcha-d --watch

trabajó para mi

Si esto sucedió de repente en su proyecto, entonces podría solucionar el problema.

Tal vez de alguna manera los archivos que estaban rastreando los cambios de su proyecto que busca el paquete web se corrompieron. Puede volver a crearlos con solo seguir unos sencillos pasos.

1. salga de su proyecto dir. ($: cd ..)
2. mueva su proyecto a un directorio diferente ($: mv {projectName} {newName})
3. entrar en el nuevo directorio ($: cd {newName})
4. inicie el servidor y verifique si se vuelve a cargar con cada cambio de archivo (debería funcionar en la mayoría de los casos, porque ahora el paquete web crea nuevos archivos para observar los cambios)
5. salir del directorio ($: cd ..)
6. muévelo de nuevo a su nombre original ($: mv {newName} {projectNam}) Esto funcionó para mí ............

Me encontré con esta pregunta cuando tenía un problema similar: parecía que el paquete web no se reagrupaba, incluso cuando se ejecutaba el paquete web --config.

Incluso eliminé bundle.js y la página web todavía se mostraba como antes de mis ediciones.

Para aquellos de ustedes que tienen este mismo problema, finalmente hice la opción 'vaciar caché y recargar duro' en Chrome (haga clic derecho en el botón de recarga con las herramientas de desarrollo abiertas) y eso hizo ese truco

Encontré el mismo problema, intenté muchas cosas, finalmente Chrome Clear Browsing Data en Mac funcionó para mí.

Se han instalado estos módulos:

"browser-sync": "^ 2.26.7",

"browser-sync-webpack-plugin": "^ 2.2.2",

"paquete web": "^ 4.41.2",

"webpack-cli": "^ 3.3.9"

El problema estaba en la diferenciación entre archivos .js y .ts. Por qué ?

En la construcción del proyecto, Visual Studio compila archivos mecanografiados en .js y .js.map. Esto es totalmente innecesario, porque webpack también maneja archivos mecanografiados (con awesome-typescript-loader). Al editar archivos componet .tsx en Visual Studio Code o con compileOnSave deshabilitado opción en tsconfig.json, el archivo ts editado no se vuelve a compilar y mi paquete web estaba procesando un archivo .js no actual.

La solución fue deshabilitar la compilación de archivos mecanografiados en Visual Studio en la construcción del proyecto. Añadir

<TypeScriptCompileBlocked>true</TypeScriptCompileBlocked>

en PropertyGroup de su .csproj.