(Pour voir ce document formaté en HTML dans VS Code, utilisez Cmd+Shift+V sur OSX ou Ctrl+Shift+V sur Linux/Windows).
Ça se produit généralement quand un fichier qui exportait jusque-là un certain type d’objet (ex. fonction) se met à en exporter un autre (ex. classe) ; ça va gêner le Hot Module Replacement, parfois plus spécifiquement React Hot Loader.
Ça peut s'être produit suite à la modification manuelle d’un export default
ou
au résultat d’un git reset --hard
.
Solution : il suffit de rafraîchir la page pour revenir d’aplomb.
Arrive, assez rarement, suite à un git reset --hard
. C’est généralement dû à
un souci de cache HardSource.
Solution : tenter, dans cet ordre :
- Rafraîchir la page
- Redémarrer Webpack (Restart Task > npm start dans VSCode)
- Purger le cache HardSource
Par exemple, vous aviez un conflit Git que vous avez arbitré, il le voit toujours.
Commencez par bien vous assurer que vous avez sauvé le fichier. Ça arrive aux meilleurs d'oublier, surtout si vous avez l'habitude de l'auto-save, qui est une plaie avec du Hot Replacement…
Si le fichier est bien sauvé mais qu’il n’y a rien à faire, purgez le cache HardSource.
Si Webpack persiste à interrompre le build en raison d’une erreur de formatage de classe prettier/prettier, mais que dans VSCode, quand vous sauvez, il ne dit rien / ne reformatte rien, vous avez peut-être une divergence de version de Prettier due au scénario suivant :
- Vous aviez ouvert VSCode alors qu’une ancienne version de Prettier était en place
- Vous avez mis à jour Prettier ensuite
- Le build s'en sert, mais l’extension Prettier de VSCode a gardé l’ancienne en mémoire.
Solution : recharger la fenêtre VSCode (Reload Window) voire le redémarrer purement et simplement.
Il peut arriver qu’en exécutant Jest (via npm test
ou npm run test:watch
par
exemple), vous ayez un affichage d’erreur parlant d’un conflit entre la version
requise de babel-core (7.0.0-bridge.0) et la version chargée (6.26.3). Cela est
dû à un décalage d’installation intermédiaire dans node_modules
. On a une
tâche de cycle de vie npm pour ça, que vous pouvez relancer si besoin :
Solution : npm run postinstall
Ça n'arrive a priori pas sur Windows. Pour les autres…
Votre sysctl
est trop léger (cas par défaut) sur le nombre total de watchers
autorisé au niveau de l'OS. Changez-le une bonne fois pour toutes et prenez-le
en compte dès maintenant grâce à la ligne de commande suivante :
echo fs.inotify.max_user_watches=524288 | sudo tee -a /etc/sysctl.conf && sudo sysctl -p
Même principe, mais les commandes sont légèrement différentes :
echo fs.inotify.max_user_watches=524288 | sudo tee -a /etc/sysctl.d/99-sysctl.conf && sudo sysctl --system
C’est un problème normalement constaté seulement sur certains OSX Sierra ou ultérieurs (High Sierra, Mojave…). C'est généralement dû à une version trop ancienne (< 4.7) dean au niveau du système. Si vous avez Homebrew, mettez à jour :
watchman shutdown-server
brew update
brew reinstall watchman
Si vous n’utilisez pas Homebrew, y’a d’autres manières.
Si ça ne marche toujours pas, Watchman est peut-être resté lancé, tentez un :
launchctl unload -F ~/Library/LaunchAgents/com.github.facebook.watchman.plist
- Arrêter Webpack
rm -fr node_modules/.cache/hard-source
(ou suppression manuelle depuis l’explorateur / le Finder)- Relancer Webpack, vérifier le build
- Rafraîchir la page pour confirmer le résultat