J'ai installé les modules de nœuds par npm install, puis j'ai essayé de faire gulp sass-watch dans l'invite de commande. Après cela, j'ai eu la réponse ci-dessous.
npm -g install gulp-cli
J'ai essayé cela avant de gorgée sass-watch
[18:18:32] Requiring external module babel-register
fs.js:27
const { Math, Object, Reflect } = primordials;
^
ReferenceError: primordials is not defined
36 Réponses :
J'ai frappé la même erreur. Je soupçonne que vous utilisez le nœud 12 et gulp 3. Cette combinaison ne fonctionne pas: https://github.com/gulpjs/gulp/issues/2324
Une solution de contournement précédente de janvier ne fonctionne pas non plus: https://github.com/gulpjs/gulp/issues/2246
Solution: mettez à niveau vers gulp 4 ou rétrogradez vers un nœud antérieur.
Rencontré le même problème avec Khaos. La rétrogradation du nœud vers la v11.15.0 a fait l'affaire.
webshot similaire ici en utilisant le webshot nœuds webshot . Je soupçonne qu'ils doivent mettre à jour quelque chose de leur côté avant de pouvoir continuer avec Node v12.
J'utilise node v12.1.0 et gulp@4.0.2 mais cela ne fonctionne pas
Nan. Ça ne marche pas. J'ai essayé toutes les saveurs ^ 4.0.0.
J'ai essayé avec node v10.x et v3.x , puis la magie s'est produite
Gardez également à l'esprit qu'il peut y avoir une dépendance sur gulp-require-tasks qui dépend actuellement de gulp@3.9. Vous aurez besoin de monkey patch celui-ci manuellement jusqu'à ce qu'un correctif soit publié.
fstream paquet fstream requis par chokidar / babel-cli a le même problème.
Même problème avec gulp ^ 3.9.1 et nodejs v12.7.0 ... J'ai décidé de passer au nœud v11.15.0 en tant que @TerjeNorderhaug et fonctionne bien
Veuillez ne pas utiliser de branche NodeJS à courte durée de vie (tous les numéros de version impairs comme 9 et 11), utilisez NodeJS 10.
Je recommanderais d'utiliser la solution npm-shrinkwrap.json publiée par Valentin: stackoverflow.com/a/58394828/2726785 , même si c'est la solution acceptée.
Avant de rétrograder le nœud vers une version antérieure, j'ai essayé de le mettre à niveau vers la dernière version v13 (13.6.0) et, pour mémoire, cela ne fonctionne pas non plus
Windows: pour moi, la mise à niveau de la version nvm vers la version 4.0.2 n'a pas aidé, ce n'est que lorsque j'ai rétrogradé le nœud (avec nvm ) à la version 11 l'erreur a disparu.
J'ai rétrogradé le nœud à la version 10 et j'ai bien fonctionné! Et pour éviter le problème, nous avons décidé d'utiliser nvm avec le fichier .nvmrc pour garantir que tout le monde exécute la même version de node.
J'utilise node v14 et gulp v4 . Et j'ai toujours le problème :(
@nZeus Avez-vous résolu votre problème? J'ai le même problème!
Eu cette erreur sans gulp (!!) installation sur l'ancienne installation v10 sur Windows en utilisant le package msi. La suppression du contenu de ce répertoire et sa réparation l'ont fait fonctionner. Pourquoi ça ne fait pas attention en premier lieu ..
@JohnyL, je l'ai fait. J'ai dû mettre à niveau toutes les bibliothèques qui dépendent de gulp 3, ainsi que gutil débarrasser de gutil ( medium.com/gulpjs/gulp-util-ca3b1f9f9ac5 ). De plus, j'avais une autre bibliothèque ( npmjs.com/package/webshot ) qui dépendait de graceful-fs - j'ai dû la remplacer également.
En fait, vous pouvez parcourir toutes les bibliothèques qui ont une dépendance sur graceful-fs et les mettre à jour / les remplacer
J'ai mis à niveau Gulp à 4 et j'ai dû résoudre quelques problèmes de tâche dans mon gulpfile.js, mais cela a fait l'affaire.
Vous pouvez également utiliser nvm pour utiliser plusieurs versions de nœud
a eu la même erreur et a finalement corrigé cela lors de la mise à jour de tous les packages, puis a mentionné la même version du moteur de nœud et la même version npm dans package.json que dans mon système de travail local.
"engines": {
"node": "10.15.3",
"npm": "6.9.0"
}
J'obtenais cette erreur lors du déploiement sur heroku.
pour plus de contrôle sur le support heroku
Il s'agit d'une solution de contournement et non d'un correctif. Parfois, nous ne pouvons pas rétrograder la version du nœud de 12 à 10.
Hé, il vous suffit de vous assurer que la version du moteur de nœud est la même sur Heroku et sur la machine locale. :)
Utiliser NVM pour gérer la version de nœud que vous utilisez, exécuter les commandes suivantes a fonctionné pour moi:
$ cd /to/your/project/ $ nvm install lts/dubnium $ nvm use lts/dubnium $ yarn upgrade # or `npm install`
Je finis toujours par y revenir.
Veuillez ne pas utiliser une branche NodeJS à courte durée de vie (tous les numéros de version impairs comme 9 et 11), utilisez NodeJS 10. Utilisez également 10 au lieu du nom de code.
Pour Windows, utilisez nvm-windows .
J'obtenais cette erreur sur Windows 10. S'est avéré être un profil itinérant corrompu.
npm ERR! node v12.4.0 npm ERR! npm v3.3.12 npm ERR! primordials is not defined npm ERR! npm ERR! If you need help, you may report this error at: npm ERR! <https://github.com/npm/npm/issues> npm ERR! Please include the following file with any support request:
La suppression du dossier C:\Users\{user}\AppData\Roaming\npm résolu mon problème.
Cela a gâché toutes mes dépendances npm, désolé.
Passez à la version 4.0.1 et assurez-vous de migrer https://fettblog.eu/gulp-4-parallel-and-series/#migration
Fait ça, pas de dés.
J'ai fait face au même problème. Ce que j'ai essayé et travaillé pour moi:
Vérifiez la version de NODE et GULP (la combinaison de node v12 et gulp less than v4 ne fonctionne pas)
Je rétrograde la version NPM en:
Cela a bien fonctionné, alors suivez simplement les instructions de votre console.
La rétrogradation vers le nœud stable a résolu ce problème pour moi, car il s'est produit après la mise à niveau vers le nœud 12
sudo n 10.16.0
Si vous essayez ceci et obtenez l'erreur: 'sudo: n: command not found', assurez-vous d'installer n abord avec: 'npm install -g n'
J'ai essayé ceci sur Windows 10 (64 bits) et obtenu: - C: \ react-script-editor> npm install -gn npm ERR! code EBADPLATFORM npm ERR! notsup Plate-forme non prise en charge pour n@6.1.0: voulu {"os": "! win32", "arch": "any"} (actuel: {"os": "win32", "arch": "x64"}) npm ERR! notsup OS valide:! win32 npm ERR! notsup Valid Arch: any npm ERR! notsup OS réel: win32 npm ERR! notsup Arche réelle: x64
Le déclassement n'est pas une option. Nous avons besoin d'un correctif et non d'une solution de pansement.
Je vous suggère d'abord de vous assurer que l' installation de NPM n'est pas votre problème. Ensuite, vous rétrogradez les versions de nœud et de gulp. J'ai utilisé le nœud 10.16.1 et gulp 3.9.1.
Pour rétrograder votre gulp, vous pouvez essayer
npm install gulp@^3.9.1
Utilisez les commandes suivantes et installez le nœud v11.15.0 :
npm install -g n sudo n 11.15.0
résoudra
ReferenceError: les primordiaux ne sont pas définis dans le nœud
Référé de @Terje Norderhaug @Tom Corelis answers.
A travaillé pour moi! Excellente réponse. J'essaye de comprendre celui-ci depuis des heures.
Réponse géniale!
Parfait! A travaillé pour moi.
Veuillez ne pas utiliser une version étrange de NodeJS. Ce sont des versions de courte durée. Utilisez NodeJS 10.
Superbe! Travaille pour moi.
Vraiment, tu m'as sauvé la vie. Merci.
Si cela ne fonctionne toujours pas, essayez ceci (après les commandes ci-dessus): npm rebuild node-sass
npm install -gn sur ma machine (Windows 64) produit une erreur: npm ERR! notsup Plate-forme non prise en charge pour n@6.1.3: wanted {"os": "! win32", "arch": "any"} (actuel: {"os": "win32", "arch": "x64"})
nvm évidemment d' utiliser un gestionnaire de version de nœud (par exemple, nvm - * NIX, y compris macOS ou Windows ) lors de la rétrogradation du nœud.
A bien fonctionné! Merci oh grand.
J'avais le nœud 12 auparavant, la rétrogradation m'a aidé.
Désinstallez le nœud et réinstallez-le en utilisant le lien donné. https://nodejs.org/en/download/
Ce qui a fonctionné pour moi était d'utiliser python2 lors de l'installation de npm.
> npm install --python=~/venv/bin/python
Utilisez les commandes suivantes pour installer le node v11.15.0 et gulp v3.9.1 :
ReferenceError: primordials is not defined in node
Résoudra ce problème:
npm install -g n sudo n 11.15.0 npm install gulp@^3.9.1 npm install npm rebuild node-sass
A travaillé pour moi, a dû suivre toutes les étapes. 👍
Veuillez ne pas utiliser de branche NodeJS à courte durée de vie (tous les numéros de version impairs comme 9 et 11), utilisez NodeJS 10.
Sérieusement, suivez toutes les étapes.
Pour ceux qui utilisent du yarn .
yarn global add n n 11.15.0 yarn install # have to install again
Veuillez ne pas utiliser de branche NodeJS à courte durée de vie (tous les numéros de version impairs comme 9 et 11), utilisez NodeJS 10.
Nous avons rencontré le même problème lors de la mise à jour d'un projet hérité en fonction de gulp@3.9.1 vers Node.js 12+.
Ces correctifs vous permettent d'utiliser Node.js 12+ avec gulp@3.9.1 en gulp@3.9.1 graceful-fs par la version ^4.2.4 .
Yarn v1 prend en charge la résolution d'un package vers une version définie . Vous devez ajouter une section de resolutions à votre package.json :
{
// Your current package.json
"scripts": {
// Your current package.json scripts
"preinstall": "npx npm-force-resolutions"
},
"resolutions": {
"graceful-fs": "^4.2.4"
}
}
Merci @jazd pour cette façon de résoudre le problème.
En utilisant npm-force-resolutions comme script de pré-installation, vous pouvez obtenir un résultat similaire à celui de yarn v1. Vous devez modifier votre package.json de cette façon:
{
// Your current package.json contents
"resolutions": {
"graceful-fs": "^4.2.4"
}
}
npm-force-resolutions modifiera le fichier package-lock.json pour définir graceful-fs sur la version souhaitée avant la fin de l' install .
Si vous utilisez un fichier .npmrc personnalisé dans votre projet et qu'il contient un proxy ou un registre personnalisé, vous devrez peut-être changer npx npm-force-resolutions en npx --userconfig .npmrc npm-force-resolutions car à partir de maintenant, npx n'utilise pas le fichier .npmrc dossier actuel par défaut.
Ce problème vient du fait que gulp@3.9.1 dépend de graceful-fs@^3.0.0 qui correspond au module Node.js fs .
Cela fonctionnait avec Node.js jusqu'à la version 11.15 (qui est une version d'une branche de développement et ne devrait pas être utilisée en production).
graceful-fs@^4.0.0 ne fait plus de monkeypatch Node.js fs module, ce qui le rend compatible avec Node.js> 11.15 (testé et fonctionnant avec les versions 12 et 14).
Notez que ce n'est pas une solution pérenne, mais cela aide lorsque vous n'avez pas le temps de mettre à jour vers gulp@^4.0.0 .
Wow - c'est génial! Je n'avais pas envie d'annuler l'installation de mon nœud, c'est donc une solution parfaite.
@Valentin cela a fonctionné pour moi, mais comment cela a-t-il fonctionné? D'après ce que j'ai lu, en plus d'être publiable, npm-shrinkwrap.json devrait se comporter de la même manière que package-lock.json. Pourquoi ne se comportent-ils pas de la même manière ici? Pourquoi npm-shrinkwrap.json est-il nécessaire pour résoudre ce problème?
Ce qu'il fait, c'est qu'il remplace la version graceful-fs par une version plus récente (v4 +) qui ne modifie plus le module nodejs fs (voir graceful-fs README). Heureusement, cela suffit pour que tout fonctionne.
Cette solution est parfaite pour cette situation particulière - elle devrait vraiment être la réponse acceptée.
Cela fonctionne mais après avoir exécuté npm install npm-shrinkwrap.json est mis à jour avec l'ancienne version. Assurez-vous de modifier à nouveau manuellement la version graceful-fs dans le fichier npm-shrinkwrap.json mis à jour sur l'entrée vinyl-fs.requires .
@AlejandroZuleta Vous avez raison de dire que l'entrée vinyl-fs a toujours graceful-fs@^3.0.0 (et aussi ~ 1.2.0) mais dans mon projet, seule graceful-fs@4.2.2 est tirée par npm via d'autres dépendances comme le montre npm ls graceful-fs .
Je suis d’accord avec plusieurs d’entre vous que cela devrait être la réponse acceptée. N'hésitez pas à voter pour le commentaire que j'ai laissé sur la réponse acceptée afin que les autres soient conscients de cette (meilleure) réponse.
Cela a fonctionné pour moi. J'ai dû installer la version 10.15.3 (qui est celle juste avant la 11.15)
Cette astuce a un effet secondaire, où il y a un mauvais résultat lors de la liste des dépendances npm en utilisant npm ls
@PuiManCheui Autant que je sache, cela n'empêche que la résolution correcte de graceful-fs pour certains paquets, non?
@Valentin lorsque j'exécute npm install pour régénérer package-lock.json ou npm-shrinkwrap.json , il semble que cela n'a pas réussi à verrouiller ces dépendances. Après avoir réexécuté npm install --no-save , le package-lock.json indique toujours à npm d'installer les dépendances manquantes.
Si vous utilisez yarn (v1), vous pouvez l'ajouter à vos résolutions dans votre package.json pour obtenir la même chose - "**/graceful-fs": "^4.0.0"
Soit le comportement a changé, soit cette solution a un certain nombre de conséquences que vous voudrez peut-être éviter. De cette façon, vous abandonnez essentiellement votre package-lock.json . Autrement dit, vos packages vont être mis à jour conformément au fichier package.json . Et c'est un hack, votre remplacement disparaîtra la prochaine fois que npm devra changer quelque chose .
@PuiManCheui J'ai supprimé le package-lock.json lors de l'utilisation d'un fichier npm-shrinkwrap.json . Vous avez raison, la solution originale n'est pas parfaite, j'ai ajouté d'autres solutions à ma réponse.
Cela permet de résoudre le problème au niveau du projet, pas au niveau global en installant un node différent. Alors merci et ayez un vote favorable.
l'ajout de la résolution pour graceful-fs 4.2.3, l'exécution de npx npm-force-resolutions puis l'exécution de npm install résout mon problème.
Cela a résolu le problème pour moi. Merci beaucoup pour cette réponse!
J'ai eu des problèmes avec NPM après cela malgré tout; le passage à Yarn l'a corrigé. Merci.
Pour les utilisateurs de npm, après avoir modifié le package.json, exécutez simplement npm install et fonctionnera comme un charme. Au fait, une solution incroyable pour ceux qui ne peuvent pas mettre à jour gulp pour le moment
J'ai eu ce problème avec le nœud 6.9.2 et gulp 3.9.1. Je l'ai corrigé en mettant à jour le nœud vers 8.11.1, puis en effectuant les étapes décrites ici dans "if ur using npm". Cependant, je tiens à souligner que npm start n'a pas fonctionné et a continué à donner cette erreur jusqu'à ce que je place le script de pré-installation tout en haut des scripts, il s'exécutera donc en premier. À part cela, cette réponse m'a vraiment aidé à comprendre cela.
node 6 n'est plus pris en charge depuis fin avril 2019, et le node 8 depuis fin 2019, vous devez donc passer au node 10 au moins et de préférence le node 12 si possible car le support du node 10 sera terminé après la fin avril 2021. Plus d'informations sur Site Web node.js pour les versions actuelles nodejs.org/en/about/releases
cela ne fonctionne pas pour moi si j'installe un autre module par la suite avec npm i bla , cela ne fonctionne que si je supprime à nouveau les node_modules et npm i , est-ce la même chose pour vous @Valentin?
@NthDegree Lorsque vous exécutez npm i bla , le script de preinstall n'est malheureusement pas exécuté et graceful-fs revient à la version sans remplacement. Vous n'avez pas besoin de supprimer vos node_modules pour résoudre le problème, exécuter npm i suffit dans mes tests. Désolé de ne pas avoir rencontré ce problème, le projet sur lequel j'utilise ce correctif n'est pas en développement actif. Je vous conseille de vous pencher sur la mise à niveau vers gulp@^4.0.0 car votre projet est activement maintenu.
Comme nous obtenons également cette erreur lorsque nous utilisons le package s3 NPM. Le problème est donc avec le paquet graceful-fs que nous devons le mettre à jour. Cela fonctionne bien sur 4.2.3.
Il suffit donc de regarder dans quel package NPM il affiche dans la trace des journaux et de mettre à jour le graceful-fs en conséquence à 4.2.3.
Gulp 3.9.1 ne fonctionne pas avec Node v12.xx, et si vous mettez à niveau vers Gulp 4.0.2, vous devez changer complètement gulpfile.js avec la nouvelle syntaxe (Series & Parallels). Donc, votre meilleur pari est de revenir à Node V 11.xx, le 11.15.0 a bien fonctionné pour moi. En utilisant simplement le code suivant dans le terminal:
nvm install 11.15.0 nvm use 11.15.0 #just in case it didn't automatically select the 11.15.0 as the main node. nvm uninstall 13.1.0 npm rebuild node-sass
Après cela, j'obtiens l'erreur: "/ c / Users / User / AppData / Roaming / npm / node: line 8: C: \ Users \ User \ AppData \ Roaming \ npm / node_modules / node / bin / node: Aucun fichier de ce type ou répertoire "
Pour toute personne ayant la même erreur pour la même raison dans ADOS CI Build:
Cette question a été la première que j'ai trouvée en cherchant de l'aide. J'ai un pipeline de construction ADOS CI où la première tâche d'installation de l'outil Node.js est utilisée pour installer Node. Ensuite, la tâche npm est utilisée pour installer gulp (npm install -g gulp). Ensuite, la tâche Gulp suivante exécute default-task à partir de gulpfile.js. Il y a des trucs gulp-sass dedans.
Quand j'ai changé l'outil Node.js pour installer le dernier nœud 12.x au lieu d'un plus ancien et la dernière version de gulp était 4.0.2. Le résultat était la même erreur que celle décrite dans la question.
Ce qui a fonctionné pour moi dans ce cas était de rétrograder node.js vers la dernière version 11.x comme cela avait déjà été suggéré par Alphonse R. Dsouza et Aymen Yaseen. Dans ce cas, il n'est pas nécessaire d'utiliser les commandes suggérées, mais définissez simplement la spécification de la version du programme d'installation de l'outil Node.js sur la dernière version de Node à partir de 11.x.
La version exacte de Node.js qui a été installée et qui fonctionne était 11.15.0. Je n'ai pas eu à rétrograder le Gulp.
J'obtenais également une erreur sur le nœud 12/13 avec Gulp 3, le passage au nœud 11 fonctionnait.
Cela peut arriver tardivement, mais pour tous ceux qui souhaitent toujours conserver leur Node v12 tout en utilisant le dernier gulp ^ 4.0, procédez comme suit:
Mettez à jour l'interface de ligne de commande (juste par précaution) en utilisant:
npm i
Ajouter / mettre à jour le gulp sous la section dépendances de votre package.json
"dependencies": {
"gulp": "^4.0.0"
}
Supprimez votre fichier package-lock.json
Supprimez votre dossier node_modules
Enfin, npm i pour mettre à niveau et recréer le tout nouveau dossier node_modules et le fichier package-lock.json avec les paramètres corrects pour Gulp ^ 4.0
npm i gulp-cli -g
Remarque Gulp.js 4.0 introduit les méthodes series() et parallel() pour combiner des tâches au lieu des méthodes de tableau utilisées dans Gulp 3, et ainsi vous pouvez ou non rencontrer une erreur dans votre ancien script gulpfile.js .
Pour en savoir plus sur l'application de ces nouvelles fonctionnalités, ce site lui a vraiment rendu justice: https://www.sitepoint.com/how-to-migrate-to-gulp-4/
( Si cela aide, veuillez laisser un bruit sourd )
A quoi gulp-cli le gulp-cli ? J'ai suivi vos pas et tout a fonctionné au départ; mais ensuite j'ai désinstallé gulp-cli (puisque je n'ai pas vu où il était utilisé), et tout fonctionnait toujours. Merci pour la réponse, car je suis à nouveau opérationnel avec le nœud v12.9.1 et Gulp 4.0.2 !
Je suis content que cela ait aidé. gulp-cli est un utilitaire de ligne de commande. Cela garantit une installation correcte de gulp Comme vous pouvez le voir dans les étapes d'installation de gulp ici: gulpjs.com/docs/en/getting-started/quick-start
J'ai résolu ce problème sur Windows 10 en désinstallant le nœud de Ajouter ou supprimer des programmes -> Node.js
Ensuite, j'ai installé la version 11.15.0 à partir de https://nodejs.org/download/release/v11.15.0/
Choisissez node-v11.15.0-x64.msi si votre Windows 64bit.
J'ai rencontré cette erreur après la mise à niveau de mon nœud vers la version 12, qui ne fonctionne pas avec Gulp 3.9.1. Concernant le fait que mon gulpfile.js n'était pas si complexe, j'ai décidé de passer à Gulp 4 en utilisant cet article , cela s'est bien passé et c'était beaucoup plus facile que je ne le pensais.
Vous avez deux options ici
Résolu en rétrogradant la version Node.js de 12.14.0 à 10.18.0 et en réinstallant node_modules .
Si vous essayez d'installer semantic-ui et que l'erreur suivante se produit, essayez de télécharger la dernière version de node js(13.5.0) avec les dernières fonctionnalités, à partir de Node.js.org.De plus, plutôt que d'essayer d'installer NPM semantic, vous devriez ajoutez simplement le lien (que vous pouvez trouver à partir du lien cdnjs vers l'en-tête de votre fichier index.html . Bonne chance!
Un exemple de code serait un excellent ajout ici.
Gulp pose un problème avec la version 11 et supérieure de Nodejs. Désinstallez votre version actuelle de nœud et réinstallez la v10.15.1 voici le lien pour cette version. Cela m'aide et cela résoudra votre problème aussi.
Gulp 3.* ne fonctionne pas sur Node 12.* ou supérieur. Vous devez rétrograder Node ou mettre à niveau Gulp.
Si vous manquez de temps, rétrograder Node vers la version v11. * Ou inférieure; si vous avez besoin de nouvelles fonctionnalités et que vous avez le temps de réparer une charge de dépendances cassées, mettez à niveau Gulp vers 4. * ou supérieur!
Comme d'autres l'ont déjà mentionné, Gulp 3.* n'est pas pris en charge sur Node 12 ou supérieur, vous devrez donc rétrograder votre version de Node à 11.* ou inférieur, OU mettre à niveau votre Gulp vers 4.0 .
La meilleure option dépend en fin de compte du temps dont vous disposez, car la mise à niveau de Gulp apporte les avantages de gulpfiles plus propres et d'un contrôle intégré sur l'exécution des tâches en série ou en parallèle , mais dépend également de la réécriture de votre gulpfile avec une nouvelle syntaxe, et pourrait (lire: probablement - voir la fin de ce commentaire) provoquer des conflits avec certaines dépendances.
C'est l'option la plus simple et la plus rapide. Surtout si vous utilisez n ou nvm , car ils vous permettent d'installer très rapidement et de basculer entre les versions de Node.
nvm install 10.16.0
n 10.16.0
Une fois que vous avez fait cela, vous devrez peut- être reconstruire vos dépendances npm ou supprimer à la fois votre dossier node_modules ET votre fichier package-lock.json et réinstaller vos dépendances. Cependant, si vous revenez simplement à une version pré-existante de Node, vous devriez probablement aller bien.
Comme mentionné ci-dessus, cette tâche prend plus de temps, mais pourrait apporter des avantages à long terme. Par exemple, Node 12 a maintenant introduit la prise en charge native des modules ES (derrière un indicateur expérimental) et une prise en charge complète dans Node 13 .
Vous devrez peut-être mettre à niveau Node pour l'utiliser, vous obligeant à mettre à niveau Gulp. Ou vous pouvez simplement souhaiter les avantages de l'utilisation de Gulp 4, car il offre un contrôle meilleur et plus efficace des tâches d'écriture.
Il existe déjà un certain nombre d'articles à ce sujet, je ne vais donc pas m'étendre davantage sur les détails, mais je le répète, ce n'est pas un travail rapide . Selon la taille de votre projet, une réécriture notable peut être nécessaire et vous pouvez avoir des dépendances qui se cassent. Si vous manquez de temps, vous devriez opter pour une simple rétrogradation de Node, au moins temporairement.
Si, comme moi, vous utilisez déjà Gulp 4+ (j'utilisais Gulp 4.0.2 , à l'origine sur Node 10) et que vous avez récemment mis à niveau (je suis passé à Node 13.8.0 ), vous rencontrez toujours le problème, il se peut que car une dépendance repose sur une version plus ancienne de Gulp, et cela se fait prendre dans le pipeline.
Dans mon cas, gulp-combine-mq était une dépendance utilisant Gulp 3.9.* . La désactivation de cette tâche dans mon gulpfile a permis à Gulp de s'exécuter à nouveau.
Si cela se produit, vous avez quelques options: vous pouvez,
Inutile de dire que si vous avez plusieurs plugins qui reposent sur une ancienne version de Gulp - en particulier si ces plugins sont vitaux pour votre application - c'est là que la mise à niveau de Gulp peut nécessiter énormément de temps supplémentaire (d'où les avertissements ci-dessus).
Si cela se produit, il est préférable de simplement rétrograder Node, au moins jusqu'à ce que des correctifs puissent être émis.
Pour moi, c'est aussi mon cas. J'utilisais Gulp 4, mais un ancien plugin gulp dépendait en interne de l'ancienne version de graceful-fs. Le coupable peut être trouvé en utilisant npm ls graceful-fs - un paquet utilisant graceful-fs avec une version inférieure à 4 causera ce problème. Supprimez-le de gulpfile, utilisez une alternative ou mettez-le à niveau pour résoudre le problème.
J'utilisais le nœud v12.13.1, donc j'ai rétrogradé à la v10.19.0 et fonctionne bien après cela.
Cette erreur est due à la nouvelle version de Node (12) et à une ancienne version de gulp (moins de 4).
La rétrogradation de Node et d'autres dépendances n'est pas recommandée. J'ai résolu ce problème en mettant à jour le fichier package.json en récupérant la dernière version de toutes les dépendances. Pour cela, j'utilise npm-check-updates . C'est un module qui met à jour le package.json avec la dernière version de toutes les dépendances.
Référence : https://www.npmjs.com/package/npm-check-updates
gulp.task('sass', gulp.series(function(done) {
return gulp.src([sourcePath + '/sass/**/*.scss', "!" + sourcePath + "/sass/**/_*.scss"])
...
done();
}));
Other config...
gulp.task(
'watch', function () {
gulp.watch(sourcePath + '/sass/**/*.scss', gulp.series('sass'));
}
);
Dans la plupart des cas, nous devrons mettre à jour le gulpfile.js ainsi que ce qui suit:
Référence : https://fettblog.eu/gulp-4-parallel-and-series/#migration
Avant:
gulp.task(
'sass', function () {
return gulp.src([sourcePath + '/sass/**/*.scss', "!" + sourcePath + "/sass/**/_*.scss"])
....
}
);
Other config...
gulp.task(
'watch', function () {
gulp.watch(sourcePath + '/sass/**/*.scss', ['sass']);
}
);
Après:
npm i -g npm-check-updates ncu -u npm install
Excellente solution si vous n'avez pas de fichiers gulp complexes. Dans mon cas, je n'ai eu qu'à adapter deux lignes par gulpfile.js. Merci pour le petit guide de migration!
Étapes pour résoudre le problème: -
J'ai résolu le problème avec les étapes suivantes: -
nvm install lts/dubniumnvm install lts/dubniumMaintenant, vous pouvez gulp déployer
Ceci est une dupe inexacte de la réponse de @kevink
C'est parce que le problème de compatibilité entre node et gulp dans votre système. La rétrogradation du node ou la mise à niveau de gulp ce problème.
sudo npm i -g n sudo n 11.15.0
Essayez de supprimer le dossier node_modules et le fichier package-lock.json et package-lock.json à l'aide de la commande npm i si cela ne fonctionne toujours pas.
Suivez simplement ces étapes . Je suis sous Windows 10 et cela a parfaitement fonctionné pour moi!
package.json créez un fichier npm-shrinkwrap.json avec le contenu suivant: {
"dependencies": {
"graceful-fs": {
"version": "4.2.2"
}
}
}
Exécutez npm install , et ne vous inquiétez pas, il npm-shrinkwrap.json à jour npm-shrinkwrap.json avec un tas de contenu.
Exécutez gulp pour démarrer le projet.
Fonctionne comme un charme sous win 10 / WSL - Merci!
A fonctionné comme un charme dans Ubuntu.
Fonctionne bien sur Win 10 pro! Merci :)
Génial! J'essayais de lancer le projet FilterBlend, mais j'ai eu cette foutue erreur. Après la mise à niveau vers gulp 4, j'ai eu une erreur différente (gulp.hasTask n'est pas une fonction). La création de ce fichier a contourné le problème.
J'ai travaillé sur OSX Catalina pour moi👍
Gloire. Win 10 pro, Gulp v3.9, Node v12.9.3, Visual Studio 2019. Je réutilise les fichiers Gulp.js pour le freelance, et je ne voulais pas passer à [Gulp] v4 pour ne réécrire aucun script. Task Runner charge maintenant toutes les tâches de Gulp, etc. Apprec!
C'était le correctif pour moi également sur MacOs Catalina - 10.15.5
J'ai les mêmes problèmes qui se sont produits et résolus de cette manière. Je vous remercie pour le soutien
Y a-t-il une version de fil de ceci?
Brillant. Fonctionne un charme.
Fonctionne comme un charme. Merci pour cette réponse!
Solution simple et élégante
Suivez simplement ces étapes. Cela fonctionnait parfaitement avec npm install s'exécutant plusieurs fois ou en installant d'autres modules ou même en publiant un projet sur un artificiel.
Dans le même répertoire où vous avez package.json, créez un fichier npm-shrinkwrap.json avec le contenu suivant:
"scripts": { "preshrinkwrap": "git checkout -- npm-shrinkwrap.json", "postshrinkwrap": "git checkout -- npm-shrinkwrap.json" }Exécutez npm install, et ne vous inquiétez pas, il mettra à jour npm-shrinkwrap.json avec un tas de contenu. Débarrassons-nous de ces mises à jour en mettant à jour les options des scripts package.json .
{ "dependencies": { "graceful-fs": { "version": "4.2.2" } } }Vous pouvez maintenant exécuter npm install et votre npm-shrinkwrap.json sera intact et fonctionnera pour toujours.
M'a sauvé de la conservation manuelle de npm-shrinkwrap.json, merci!
C'est génial de voir mon premier message sur le débordement de pile m'a aidé à être vous en tant que première personne @dblazeski :)
@saumilsdk quand j'installe un autre module par la suite, par exemple npm i bla , il n'installe que le graceful-fs + le nouveau mais tous les autres modules manquent alors, est-ce la même chose pour vous?
J'ai eu le même problème en installant le package npm https://www.npmjs.com/package/webshot
REMARQUE: il s'agissait d'un problème connu pour ce package car il dépend de graceful-fs dans les coulisses.
CORRECTIF: 1. mettre à niveau graceful-fs vers 4.x ou version ultérieure
correction: 2. utilisez plutôt webshot-node https://www.npmjs.com/package/webshot-node
Vérifier la version du nœud:
sudo npm install -g n sudo n 11.15.0
Vérifiez la version de gulp:
sudo npm install -g gulp
Si node> = 12 et gulp <= 3, effectuez l'une des opérations suivantes:
gulp -v
node --version
https://www.surrealcms.com/blog/how-to-upgrade-or-downgrade-nodejs-using-npm.html
Rétrograder en installant le programme appelé n a fonctionné pour moi. Merci
Si le problème ne vient pas de gulp vérifiez le module décompresser npm. cela fait environ six ans depuis la dernière mise à jour. cela ne fonctionne pas avec Node> v11.
Essaye ça:
npm install -g n sudo n 11.15.0
Idem avec unzip2 . Cependant, unzip2 a un remplacement qui fonctionne - node-unzip-2
J'ai essayé de nombreuses suggestions pour résoudre ce problème pour un projet existant sur ma machine Windows 10 et j'ai fini par suivre ces étapes pour le résoudre;
gulp -v , puis node -v pour vérifier qu'il a été complètement désinstallé.Veuillez noter que parfois, lorsque je passe d'une branche git à une autre, il se peut que je doive fermer mon Visual Studio et l'exécuter à nouveau en tant qu'administrateur pour que cette solution fonctionne à nouveau.
Autant que je vois, ce problème a commencé à se produire après avoir installé la dernière version recommandée (12.18.4) de Node.js pour un nouveau projet et je ne m'en suis rendu compte que lorsque certaines modifications FE n'étaient pas reflétées sur le projet Web existant.
