Réponses:
FYI: il semble qu'OS X puisse avoir un dossier corrompu et ne plus envoyer fsevents(que watchpack/ chokidar/ Finder utilise) pour lui-même et 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 immédiatement comme prévu. Voir cet article 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 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 Finder et en créant des fichiers dans chaque dossier parent successif jusqu'à ce que l'un d'eux apparaisse immédiatement (puisque Finder sera également arrosé par ce bogue). Le dossier le plus racine qui ne se met pas à jour est le coupable. Nous l'avons juste mvfait et l' avons mvremis à son nom d'origine, puis l'observateur a fonctionné.
Aucune idée de ce qui cause la corruption, mais je suis juste content d'avoir une solution.
watchify, aucune des étapes ne fonctionnait avec moi, alors j'ai fini par utiliser poll arg. Beaucoup de gens passent l'argument du sondage pour browserify au lieu de watchify. Mon code ressemble à:watchify(browserify(config.src,{}), {poll:100});
npm installet le changement de nom d'un répertoire sont des opérations très intensives de la façon dont le client de synchronisation est implémenté.
Si votre code n'est pas recompilé, essayez d'augmenter le nombre d'observateurs (dans Ubuntu):
echo fs.inotify.max_user_watches=524288 | sudo tee -a /etc/sysctl.conf && sudo sysctl -psudo sysctl -pne fonctionne pas sur Mavericks. Des nouvelles idées?
ModuleConcatenationPlugin . Omettre ModuleConcatenationPluginpermet de continuer à regarder.
/etc/sysctl.confdirectement? Changer resp. régler cette valeur-clé? (Si vous ne trouvez pas la commande pour appliquer ad-hoc ( sysctl -p), eh bien, c'est un seul redémarrage, et vous devriez être bon ...)
sudo sysctl -a | grep max_user_watches
L'ajout du code suivant à mon fichier de configuration Webpack a résolu le problème pour moi, j'espère que cela vous aidera. N'oubliez pas d'ignorer votre dossier node_modules, car cela tuerait les performances de HMR (Hot Module Replacement):
watchOptions: {
poll: true,
ignored: /node_modules/
}
watch: truepeut donc fonctionner également. L'interrogation est la vérification continue d'autres programmes ou périphériques par un programme ou un périphérique pour voir dans quel état ils se trouvent, généralement pour voir s'ils sont toujours connectés ou s'ils souhaitent communiquer. Ainsi, le paramétrage poll: truepermet à Webpack de vérifier l'état de votre programme pour voir si des modifications ont été apportées, ou du moins ce que je suppose se passe.
J'ai eu ce problème en travaillant avec WebStorm.
La désactivation des paramètres -> Paramètres système -> "écriture sécurisée" l'a résolu pour moi.
Vous avez trouvé la recommandation de le faire dans: Dépannage WebPack
Juste pour ajouter aux solutions possibles: j'avais mon dossier de projet dans un dossier Dropbox, le déplacer a résolu le problème pour moi. (OS X)
La sensibilité à la casse des dossiers était mon problème. Mes appels de code à require () avaient tous les noms de chemin en minuscules MAIS les répertoires en fait contenaient une lettre majuscule. J'ai renommé tous mes répertoires en minuscules et l'observation des packs Web a fonctionné instantanément.
Un problème est que si vos noms de chemin ne sont pas absolus, des choses comme celle-ci se produiront. J'avais accidentellement réglé sur resolve.rootau ./lieu de __dirnameet cela m'a fait perdre beaucoup de temps à supprimer et recréer des fichiers comme les gars au-dessus de moi.
Si la modification de fs.inotify.max_user_watches comme indiqué par César ne fonctionne toujours pas, essayez d'utiliser l'interrogation au lieu des observateurs natifs en créant votre script comme indiqué dans la documentation ou en exécutant le webpack avec des --watch --watch-polloptions.
Notez que si vous exécutez webpack dans une machine virtuelle (Vagrant / Virtualbox) et que vous modifiez vos fichiers sur la plate-forme hôte, les mises à jour de fichiers dans le dossier partagé peuvent ne pas déclencher inotify sur Ubuntu. Cela empêchera les modifications d'être prises en compte par webpack.
voir: Virtualbox ticket # 10660
Dans mon cas, l'édition et l'enregistrement du fichier sur l'invité (dans vi) ont déclenché le webpack. Le modifier sur l'hôte (dans PhpStorm, Notepad ou toute autre application) ne déclenchera PAS le webpack quoi que je fasse.
Je l'ai résolu en utilisant vagrant-fsnotify .
vagrant-notify-forwarderpour plus de rechargement magique
vagrant plugin install vagrant-notify-forwarderfait une solution permanente pour moi
Travaillez pour moi à Laravel Homestead
--watch --watch-pollMises à jour: la suppression de tout le répertoire et le clonage git à nouveau du dépôt résout mon problème.
Si vous utilisez Vim, vous devriez essayer de définir backupcopy sur yes plutôt que sur auto par défaut. Sinon, Vim renomme parfois le fichier d'origine et en crée un nouveau, ce qui va gâcher la montre Webpack:
https://github.com/webpack/webpack/issues/781
Ajoutez simplement ceci à vos paramètres vim si tel est le cas:
set backupcopy = oui
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 ne s'est plus recompilé. Le problème concernait le chemin du fichier d'importation dont une lettre était en majuscule. Il est très difficile de comprendre ce problème car tout fonctionne lors d'un redémarrage du serveur. Vérifiez le cas de vos chemins.
Ce n'était pas une recompilation pour moi, mais j'ai ensuite réalisé / me suis souvenu que Webpack surveille le graphique de dépendance et pas seulement un dossier (ou des fichiers). Bien sûr, les fichiers que je modifiais ne faisaient pas encore partie de ce graphique.
Pour moi, la création de dossiers et de fichiers dans VS Code était le problème. Pour réparer, j'ai recloné mon dépôt et cette fois, 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 juste mise à jour alors peut-être que c'est un nouveau bogue.
J'ai eu un problème similaire, ni le webpack ni le rollup en mode montre n'attrapent les modifications que j'ai apportées. J'ai découvert que c'était essentiellement ma faute car je changeais de module (fichier .tsx) qui n'était encore importé nulle part dans l'application (par exemple App.ts qui est le point d'entrée) et je m'attendais à ce que les outils de construction rapportent les erreurs. fait là-bas.
La façon dont j'ai résolu le problème a été de trouver une erreur de capitalisation dans un chemin d'importation. Le dossier sur le système de fichiers avait la première lettre minuscule, le chemin d'importation était en majuscules. Tout s'est bien compilé, il ne s'agissait donc que d'un problème d'inclusion de montre Web.
Il y avait également ce problème dans une VM Ubuntu (18.04) VirtualBox (5.2.18) utilisant Vagrant (2.1.15) avec synchronisation rsync. Du coup, la première compilation fonctionne bien mais Webpack ne prend pas en compte les changements par la suite, même avec fs.inotify.max_user_watches=524288set. L'ajout poll: truede la configuration Webpack n'a pas non plus aidé.
Seulement vagrant-notify-forwarderfonctionné (vagrant-fsnotify n'a pas fait, pour une raison quelconque), mais la reconstruction s'est produite trop rapidement après avoir enregistré le fichier sur l'hôte et je suppose que rsync n'a pas eu assez de temps pour terminer sa tâche (peut-être en raison du montant des répertoires synchronisés dans mon Vagrantfile?).
Enfin, j'ai fait à nouveau fonctionner la montre en augmentant également la aggregateTimeoutconfiguration de ma configuration Webpack:
module.exports = {
watch: true,
watchOptions: {
aggregateTimeout: 10000
},
...
}Si cette solution fonctionne pour vous, essayez de réduire à nouveau cette valeur, sinon vous devrez attendre 10 secondes jusqu'à ce que la compilation redémarre à chaque fois que vous appuyez sur Enregistrer. La valeur par défaut est de 300 ms .
Pour moi, la suppression node_moduleset la refonte de npm install ou yarn pour installer tous les packages ont résolu le problème
Il semble que la valeur de: max_user_watches
dans le /proc/sys/fs/inotify/max_user_watches
Webpack affecte
Pour vérifier votre valeur réelle
$cat /proc/sys/fs/inotify/max_user_watches
1638416384 était dans mon cas et ce n'était toujours pas suffisant.
J'ai essayé différents types de solutions comme:
$ echo fs.inotify.max_user_watches=100000 | sudo tee -a /etc/sysctl.conf
$ sudo sysctl -pMais il semble que même si j'ai changé la valeur, lorsque j'ai redémarré mon PC, il reviendrait à la valeur par défaut 16384.
Créez le fichier:
sudo nano /etc/sysctl.d/90-override.conf
Et remplissez-le avec:
fs.inotify.max_user_watches=200000
Il me semble que 200 000 me suffisent.
Après avoir créé le fichier et ajouté la valeur, redémarrez simplement le PC et tout devrait aller.
Une solution simple sur MacOS est la suivante:
Ouvrez deux fenêtres de terminal dans le même répertoire que votre projet réside.
Dans la première fenêtre de terminal, exécutez: webpack --watch
Dans le deuxième terminal, les fenêtres exécutent: webpack-dev-server
J'ai essayé de nombreuses solutions possibles et cela semble être la plus fiable
webpack --watchcompile le projet et enregistre les fichiers sur le disque, ce qui équivaut à une exécution webpackaprès chaque sauvegarde. webpack-dev-serverest un outil de développement qui compile en mémoire et sert le contenu comme un service sur http. Dans tous les cas, votre suggestion n'est pas une solution, car les fichiers compilés ne seront pas écrits sur le disque tant qu'ils webpack --watchne fonctionneront pas comme annoncé ..
Solution possible: changement de contexte dans le répertoire de l'application.
J'avais tous mes fichiers de configuration webpack dans un sous-dossier:
components/
webpack/
development.js
app.jsDans webpack/development.js, set a context: path.join(__dirname, '../')résolu mon problème.
Après avoir essayé une poignée de stratégies pour résoudre ce problème, j'ai fini par abandonner, mais en résolvant un autre problème, j'ai réessayé et tout d'un coup, le --watchdrapeau fonctionnait enfin.
Pour être honnête, je ne sais pas ce qui l'a spécifiquement fait fonctionner, mais après avoir effectué les étapes suivantes, il a 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 est peut-être arrivé que lors de l'installation de ces packages, certaines dépendances aient simplement ajouté la pièce manquante du puzzle, qui sait ...
J'espère que cela aidera quiconque a du mal à le faire fonctionner.
J'ajoute une autre réponse car je pense que c'est la meilleure solution à ce jour. Je l'utilise tous les jours et ça déchire! Installez simplement cette bibliothèque:
https://github.com/gajus/write-file-webpack-plugin
Description: force le programme webpack-dev-server à écrire des fichiers bundle dans le système de fichiers.
Comment installer :
npm install write-file-webpack-plugin --save-devSi cela se produit soudainement dans votre projet, cela peut résoudre le problème.
Peut-être que d'une manière ou d'une autre, les fichiers qui suivaient les modifications de votre projet recherché par Webpack ont été corrompus. Vous pouvez les recréer simplement en suivant des étapes simples.
Je suis tombé sur cette question alors que j'avais un problème similaire - il est apparu que webpack ne rebondissait pas, même lors de l'exécution de webpack --config.
J'ai même supprimé bundle.js et la page Web s'affichait toujours comme avant mes modifications.
Pour ceux d'entre vous qui rencontrent le même problème, j'ai finalement fait l'option `` cache vide et rechargement dur '' dans chrome (cliquez avec le bouton droit sur le bouton de rechargement avec les outils de développement ouverts) et cela a fait cette astuce
Le problème était de distiction entre les fichiers .js et .ts. Pourquoi ?
Lors de la génération du projet, Visual Studio compile les fichiers dactylographiés en .js et .js.map. Ceci est totalement inutile, car webpack gère également les fichiers dactylographiés (avec awesome-typescript-loader). Lors de la modification de fichiers .tsx de composants dans Visual Studio Code ou avec l' option compileOnSave désactivée dans tsconfig.json, le fichier ts modifié n'est pas recompilé et mon pack Web traitait un fichier .js non réel.
La solution était de désactiver la compilation des fichiers dactylographiés dans Visual Studio lors de la construction du projet. Ajouter
<TypeScriptCompileBlocked>true</TypeScriptCompileBlocked>dans PropertyGroup de votre .csproj.