webpack --watch ne compile pas les fichiers modifiés
J'ai essayé d'exécuter webpack --watch et après l'édition de mes fichiers JS, cela ne déclenche pas une recompilation automatique.
J'ai essayé de réinstaller webpack en utilisant npm uninstall mais cela ne fonctionne toujours pas.
Des idées?
Pour info: il semble que OS X puisse corrompre un dossier et ne plus envoyer fsevents (que watchpackchokidar/Finder utilise) pour lui-même et tous les dossiers enfants. Je ne peux pas être sûr que c'est ce qui vous est arrivé, mais c'était très frustrant pour moi et un collègue.
Nous avons pu renommer le dossier parent corrompu, puis regarder les événements se dérouler comme prévu. Voir ce billet de blog pour plus d'informations: http://feedback.livereload.com/knowledgebase/articles/86239-os-x-fsevents-bug-may-prevent-monitoring-of-certai
Les correctifs recommandés à partir du lien ci-dessus sont les suivants:
- redémarrer l'ordinateur
- vérification du disque et réparation des autorisations via l'utilitaire de disque
- ajout du dossier à la liste de confidentialité Spotlight (la liste des dossiers à ne pas indexer), puis suppression de celle-ci, forçant effectivement une réindexation
- _/renommer le dossier, puis éventuellement le renommer
- recréer le dossier et y replacer l'ancien contenu
Les deux premiers n'ont pas fonctionné pour nous, n'ont pas essayé la suggestion Spotlight et la recréation ne s'est pas avérée nécessaire.
Nous avons pu trouver le dossier du problème racine en ouvrant le Finder et en créant des fichiers dans chaque dossier parent successif jusqu'à ce qu'un d'entre eux apparaisse immédiatement (car le Finder sera également affecté par ce bogue). Le dossier le plus root qui ne se met pas à jour est le coupable. Nous avons juste mv 'et mv' pour lui redonner son nom d'origine, puis l'observateur a fonctionné.
Aucune idée de ce qui cause la corruption, mais je suis simplement content d'avoir une solution.
Si votre code n'est pas en cours de recompilation, essayez d'augmenter le nombre d'observateurs (sous Ubuntu):
echo fs.inotify.max_user_watches=524288 | Sudo tee -a /etc/sysctl.conf && Sudo sysctl -p
L'ajout du code suivant dans le fichier de configuration de mon pack Web a résolu le problème, espérant que cela aidera . N'oubliez pas d'ignorer votre dossier node_modules, car cela réduirait les performances de HMR (Hot Module Replacement):
watchOptions: {
poll: true,
ignored: /node_modules/
}
J'ai eu ce problème lorsque je travaille avec WebStorm.
La désactivation de Paramètres -> Paramètres système -> "écriture sécurisée" a résolu le problème pour moi.
A trouvé la recommandation de le faire dans: Dépannage WebPack
Juste pour ajouter des solutions possibles: J'ai eu mon dossier de projet dans un dossier Dropbox, le déplacer en dehors a résolu le problème pour moi. (OS X)
Un problème est que si vos noms de chemin ne sont pas absolus, des événements comme celui-ci se produiront. J'avais accidentellement réglé resolve.root sur ./ au lieu de __dirname, ce qui m'a fait perdre beaucoup de temps à supprimer et à recréer des fichiers comme ceux qui sont au-dessus de moi.
Si vous modifiez fs.inotify.max_user_watches comme point de sortie par César ne fonctionne toujours pas, essayez d'utiliser l'interrogation au lieu d'observateurs natifs en créant votre script comme indiqué dans docs ou en exécutant Webpack avec les options --watch --watch-poll.
Si vous utilisez Vim, essayez de définir backupcopy sur yes plutôt que sur auto par défaut. Sinon, Vim renommera parfois le fichier d'origine et en créera un nouveau, ce qui gâchera la surveillance de WebPack:
https://github.com/webpack/webpack/issues/781
Ajoutez simplement ceci à vos paramètres vim si c'est le cas:
set backupcopy = yes
Mises à jour: la suppression de tout le répertoire et la remise à jour du clonage git du référentiel résolvent mon problème
Notez que si vous exécutez webpack sur une machine virtuelle (Vagrant/Virtualbox) et que vous modifiez vos fichiers sur la plate-forme hôte, les mises à jour de fichier dans le dossier partagé peuvent ne pas déclencher inotify sur Ubuntu. Cela fera en sorte que les modifications ne soient pas récupérées par WebPack.
voir: Ticket Virtualbox # 10660
Dans mon cas, éditer et sauvegarder le fichier sur de guest (in vi) a déclenché webpack. Le modifier sur l'hôte (dans PhpStorm, Notepad ou toute autre application) n'a PAS déclenché webpack quoi que je fasse.
Je l'ai résolu en utilisant vagrant-fsnotify .
J'avais le même problème sur un fichier .vue . Lorsque le serveur a redémarré, tout fonctionnait correctement, mais lors de la sauvegarde suivante, il n'était plus recompilé. Le problème concernait le chemin du fichier d'importation dans lequel une lettre avait été mise en majuscule. Il est très difficile de comprendre ce problème car tout fonctionne au redémarrage du serveur. Vérifiez le cas de vos chemins.
Yo !!!! La sensibilité des dossiers était mon problème. Mes appels de code à require () avaient tous les noms de chemin minuscules MAIS les répertoires avaient en réalité une lettre majuscule. J'ai renommé tous mes répertoires en minuscules et regarder des packs Web a fonctionné instantanément. YESssssssssssssss !!!!! _AckerApple
Pour moi, la création de dossiers et de fichiers dans VS Code était le problème. Pour réparer, j'ai re-cloné mon référentiel et cette fois-ci, j'ai créé de nouveaux dossiers et fichiers via la ligne de commande au lieu de Code. Je pense que Code corrompait les fichiers pour une raison quelconque. J'ai vu l'application qui vient d'être mise à jour, alors c'est peut-être un nouveau bogue.
Ce n’était pas une recompilation pour moi, mais j’ai ensuite réalisé que Webpack surveillait le graphe de dépendance et pas seulement un dossier (ou des fichiers). Bien sûr, les fichiers que je changeais ne faisaient pas encore partie de ce graphique.
Travailler pour moi à Laravel Homestead
--watch --watch-poll
J'ai résolu le problème en trouvant une erreur de capitalisation dans un chemin d'importation. Le dossier du système de fichiers avait la première lettre en minuscule, le chemin d'importation était en majuscule. Tout était bien compilé, donc c'était juste un problème d'inclusion de la montre webpack.
J'ai le même problème. Et je remarque que ce n'est pas en train de compiler car mon dossier contient du caractère (*). Et l’utilisation de l’ancien plug-in watcher semble résoudre le problème… .. Ajoutez cette ligne à votre fichier de configuration webpack.
plugins: [
new webpack.OldWatchingPlugin()
]
J'avais un problème similaire, ni webpack ni rollup en mode veille ne détectant les modifications apportées. J'ai découvert que c'était essentiellement ma faute, car je changeais de module (fichier .tsx) qui n'était pas encore importé nulle part dans l'application (par exemple, App.ts, qui constitue le point d'entrée) et je m'attendais à ce que les outils de compilation signalent des erreurs. fait là.
Pour moi, supprimer node_modules et effectuer npm install ou yarn à nouveau pour installer tous les paquetages a résolu le problème
Je suis tombé sur cette question alors que je rencontrais un problème similaire - il est apparu que Webpack n'était pas un nouveau financement, même lors de l'exécution de webpack --config.
J'ai même supprimé bundle.js et la page Web était toujours affichée comme avant mes modifications.
Pour ceux d’entre vous qui ont le même problème, j’ai finalement fait l’option 'cache vide et rechargement dur' en chrome (clic droit sur le bouton de rechargement avec devtools ouvert) et c’est ce qui a été joué
Solution possible: changer context dans le répertoire app.
J'ai eu tous mes fichiers de configuration webpack dans un sous-dossier:
components/
webpack/
development.js
app.js
Dans webpack/development.js, set context: path.join(__dirname, '../') a résolu mon problème.
Si cela se produisait soudainement dans votre projet, cela pourrait résoudre le problème.
Peut-être que d’une manière ou d’une autre, les fichiers qui suivaient votre projet ont été corrompus. Vous pouvez les recréer simplement en suivant des étapes simples.
- sortir de votre projet dir. ($: cd ..)
- déplacez votre projet dans un répertoire différent ($: mv {nomduprojet} {nouveauNom})
- entrer dans le nouveau répertoire ($: cd {newName})
- démarrez le serveur et vérifiez s'il est rechargé à chaque changement de fichier (cela devrait fonctionner dans la plupart des cas, car webpack crée maintenant de nouveaux fichiers pour surveiller les modifications)
- sortir du répertoire ($: cd ..)
- remettez-le à son nom d'origine ($: mv {newName} {projectNam}) Cela a fonctionné pour moi ............
Après avoir essayé quelques stratégies pour résoudre ce problème, j'ai fini par abandonner mais, tout en résolvant un autre problème, j'ai réessayé et tout d'un coup le drapeau --watch a finalement fonctionné.
Pour être honnête, je ne sais pas ce qui a précisément fonctionné, mais après avoir exécuté les étapes suivantes, il a juste commencé à fonctionner:
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++
Il se peut que lors de l’installation de ces paquets, des dépendances viennent d’ajouter la pièce manquante du puzzle, qui sait ...
J'espère que cela aidera tous ceux qui luttent pour que cela fonctionne.
J'ajoute une autre réponse parce que je crois que c'est la meilleure solution jusqu'à présent… .. Je l'utilise tous les jours et c'est génial!…. Il suffit d'installer cette bibliothèque:
https://github.com/gajus/write-file-webpack-plugin
Description: Force le programme webpack-dev-server à écrire des fichiers d'ensembles dans le système de fichiers.
Comment installer :
npm install write-file-webpack-plugin --save-dev
Essayez de changer --watch en -d --watch
a travaillé pour moi
Une solution simple sur MacOS est la suivante:
Ouvrez deux fenêtres de terminal dans le même répertoire que votre projet.
Dans la première fenêtre du terminal, lancez: webpack --watch
Dans la deuxième fenêtre du terminal, lancez: webpack-dev-server
J'ai essayé beaucoup de solutions possibles et cela semble être la plus fiable
Ce problème était également lié à une VirtualBox (5.2.18) Ubuntu (18.04) VM utilisant Vagrant (2.1.15) avec la synchronisation rsync. Soudain, la première construction fonctionne très bien, mais Webpack ne prend pas les modifications en compte par la suite, même avec fs.inotify.max_user_watches=524288 set. L'ajout de poll: true dans la configuration Webpack n'a pas non plus aidé.
Seul vagrant-notify-forwarder fonctionnait (vagrant-fsnotify n’avait pas, pour une raison quelconque), mais la reconstruction s’est faite trop rapidement après avoir enregistré le fichier sur l’hôte et je suppose que rsync n’a pas eu le temps de terminer sa tâche ( peut-être en raison de la quantité de répertoires synchronisés dans mon Vagrantfile?).
Enfin, j'ai à nouveau fait fonctionner la montre en augmentant également le aggregateTimeout dans ma configuration Webpack:
module.exports = {
watch: true,
watchOptions: {
aggregateTimeout: 10000
},
...
}
Si cette solution vous convient, essayez de réduire à nouveau cette valeur, sinon vous devrez attendre 10 secondes jusqu'à ce que la construction redémarre chaque fois que vous appuyez sur Enregistrer. La valeur par défaut est 300 ms .