4
votes

Webpack échoue soudainement à se compiler en raison des erreurs "Module non trouvé: Erreur: Impossible de résoudre"

Depuis hier après-midi, notre suite de tests unitaires Javascript a commencé à échouer. Aucun des tests ne s'exécute et Webpack ne signale un échec de construction après une chaîne d'erreurs Module non trouvé. Voici notre pile de construction:

Node 6.11.5 (oui je sais, très ancien) Karma 1.7.1 Webpack 2.2.1 React 15.6.2

Nous exécutons nos tests unitaires en utilisant Karma. La plupart de la suite de tests implique React, nous utilisons donc Webpack pour tout construire. Pour ce faire, nous importons notre configuration webpack puis insérons diverses valeurs dans la configuration webpack Karma.

Construire les scripts directement à l'aide de Webpack fonctionne bien, mais lorsque nous essayons d'exécuter karma start nous obtenons beaucoup de ces erreurs:

ubuntu@ip-172-17-108-178:/workspace/assets-build/build-js$ npm list es-abstract
admin@0.0.1 /workspace/assets-build/build-js
├─┬ enzyme@3.10.0
│ ├─┬ array.prototype.flat@1.2.3
│ │ └── es-abstract@1.17.0-next.1
│ ├─┬ object.entries@1.1.1
│ │ └── es-abstract@1.17.0-next.1
│ └─┬ string.prototype.trim@1.2.0
│   └── es-abstract@1.16.3  deduped
├─┬ enzyme-adapter-react-15@1.4.1
│ ├─┬ enzyme-adapter-utils@1.12.1
│ │ ├─┬ airbnb-prop-types@2.15.0
│ │ │ └─┬ array.prototype.find@2.1.0
│ │ │   └── es-abstract@1.16.3  deduped
│ │ └─┬ object.fromentries@2.0.2
│ │   └── es-abstract@1.17.0-next.1
│ └─┬ object.values@1.1.1
│   └── es-abstract@1.17.0-next.1
├─┬ eslint-plugin-jsx-a11y@6.2.3
│ └─┬ array-includes@3.1.0
│   └── es-abstract@1.17.0-next.1
└─┬ object.values@1.0.4
  └── es-abstract@1.16.3

Tous ces problèmes semblent être liés à es-abstract , dont nous avons remarqué qu'il y avait une nouvelle version hier (1.17.0-next.1). C'est à peu près au moment où tout a commencé à échouer. Cela dit, le package semble avoir téléchargé et installé correctement:

ERROR in ./~/object.entries/implementation.js
Module not found: Error: Can't resolve 'es-abstract/2019/RequireObjectCoercible' in '/jenkins/workspace/RFD/DCS/assets-build/build-js/node_modules/object.entries'
 @ ./~/object.entries/implementation.js 3:29-79
 @ ./~/object.entries/index.js
 @ ./~/enzyme/build/Utils.js
 @ ./~/enzyme/build/ReactWrapper.js
 @ ./~/enzyme/build/index.js
 @ ../sources/admin/js/pages/sponsored/organic_flyers/tests/DealerAddButton.spec.jsx

ERROR in ./~/object.fromentries/implementation.js
Module not found: Error: Can't resolve 'es-abstract/2019/AddEntriesFromIterable' in '/jenkins/workspace/RFD/DCS/assets-build/build-js/node_modules/object.fromentries'
 @ ./~/object.fromentries/implementation.js 3:29-79
 @ ./~/object.fromentries/index.js
 @ ./~/enzyme-adapter-utils/build/Utils.js
 @ ./~/enzyme-adapter-utils/build/index.js
 @ ./~/enzyme-adapter-react-15/build/ReactFifteenAdapter.js
 @ ./~/enzyme-adapter-react-15/build/index.js
 @ ../sources/admin/js/pages/sponsored/organic_flyers/tests/DealerAddButton.spec.jsx

ERROR in ./~/object.fromentries/implementation.js
Module not found: Error: Can't resolve 'es-abstract/2019/CreateDataPropertyOrThrow' in '/jenkins/workspace/RFD/DCS/assets-build/build-js/node_modules/object.fromentries'
 @ ./~/object.fromentries/implementation.js 4:32-85
 @ ./~/object.fromentries/index.js
 @ ./~/enzyme-adapter-utils/build/Utils.js
 @ ./~/enzyme-adapter-utils/build/index.js
 @ ./~/enzyme-adapter-react-15/build/ReactFifteenAdapter.js
 @ ./~/enzyme-adapter-react-15/build/index.js
 @ ../sources/admin/js/pages/sponsored/organic_flyers/tests/DealerAddButton.spec.jsx

ERROR in ./~/object.fromentries/implementation.js
Module not found: Error: Can't resolve 'es-abstract/2019/Get' in '/jenkins/workspace/RFD/DCS/assets-build/build-js/node_modules/object.fromentries'
 @ ./~/object.fromentries/implementation.js 5:10-41
 @ ./~/object.fromentries/index.js
 @ ./~/enzyme-adapter-utils/build/Utils.js
 @ ./~/enzyme-adapter-utils/build/index.js
 @ ./~/enzyme-adapter-react-15/build/ReactFifteenAdapter.js
 @ ./~/enzyme-adapter-react-15/build/index.js
 @ ../sources/admin/js/pages/sponsored/organic_flyers/tests/DealerAddButton.spec.jsx

Et quand node_modules manuellement le répertoire node_modules , je peux voir tous les fichiers que je m'attendrais à voir, sur la base d'un examen rapide de l'es-abstract Github. Je ne peux pas comprendre pourquoi Webpack ne peut apparemment pas voir ces fichiers alors qu'ils sont installés au bon endroit. Je ne peux pas non plus comprendre pourquoi cela se briserait soudainement depuis hier, à moins que quelque chose n'allait pas avec le paquet es-abstract. Mais si tel est le cas, personne n'a signalé de problème à aucun des projets concernés (qui incluent Enzyme et certains des shims ES) ou au projet es-abstract lui-même. En outre, en regardant les builds CI pour certains des projets concernés, ils semblent tous signaler des tests réussis.

Nous ne savons pas quoi faire. J'ai essayé d'effacer node_modules et d' npm install partir de zéro, de mettre à niveau Node vers la v8 LTS, de rétrograder Enzyme et l'adaptateur React pour essayer d'extraire une ancienne version d'es-abstract (qui ne fonctionne pas, leur package.json les fichiers demandent toujours ^1.17.0-next.1 , ce qui n'a aucun sens pour moi étant donné que certaines de ces versions ^1.17.0-next.1 un an). Rien ne fonctionne.


8 commentaires

Nous avons également eu le même problème. J'ai créé un numéro pour ce github.com/ljharb/es-abstract/issues/83 . Vous pouvez peut-être obtenir des notifications et des solutions à partir de là.


Nous rencontrons également le problème décrit. Je n'ai pas encore trouvé de solution. Nous utilisons également une version React 15.x et Webpack 2.x car il s'agit d'un projet "hérité". J'ai pratiquement suivi le même processus de débogage qu'OP et j'ai pu trouver les fichiers "manquants" dans le dossier node_modules d'es-abstract. Je n'ai aucune idée.


Nous utilisons également des versions fixes pour ne pas avoir de problèmes de ce genre - l'un d'eux est une bibliothèque appelée react-dates@10.1.1 <- qui est une version vieille de 3 ans. MALHEUREUSEMENT React dates a une dépendance à "airbnb-prop-types": "^ 2.4.1" avec une version dynamique -> La dernière version de airbnb-prop-types 2.15 vient de se produire il y a quelques jours, qui incluait es-abstract@1.17.0 -next.1 version


puisque la bibliothèque qui a ajouté la version dynamique requise ne semble plus être correctement maintenue (443 problèmes en suspens et 70 PR ouverts) je vais la bifurquer et m'auto-héberger


Quelle «application dynamique nécessite»? l'enzyme est entièrement maintenue, tout comme les types airbnb-prop. C'est une mauvaise configuration de Webpack et rien de plus. Veuillez signaler les problèmes github pour ces choses.


github.com/ljharb/es-abstract/issues/84#issuecomment-5676349‌ 75


Juste comme une note aléatoire, nous avons fini par contourner ce problème en tirant temporairement Enzyme pour éviter complètement le problème. Nous envisageons cependant de passer à Jest, ce qui pourrait nous donner l'occasion d'essayer la résolution de module personnalisée ci-dessous. De plus, nous devrions probablement nous pencher sur la mise à niveau de Node.


Eu le même problème. Je l'ai résolu ici stackoverflow.com/a/64895428/10944219


3 Réponses :


0
votes

J'ai créé un problème sur le référentiel github des responsables https://github.com/ljharb/es-abstract/issues/84#issuecomment-567422831

Puisque nous rencontrons exactement le même problème, nous sommes allés avec une idée qui a été décrite par un commentaire. Exécution de la version de développement Webpack sous l'indicateur de production . Pour nous, toutes les entrées de source-map sont conservées et notre application de développement est entièrement débogable. Nous utilisons donc cela comme une solution de contournement.

Si jamais cela se rompt à l'avenir, nous allons probablement bifurquer tous les référentiels qui sont allés avec une dépendance de plage semver et l'héberger nous-mêmes pour nos dépôts hérités vraiment obsolètes.


0 commentaires

1
votes

J'ai eu ce problème et je l'ai résolu en corrigeant les paramètres de résolution de mes modules dans Jest.

Avec l'état actuel des choses, mon package-lock comprend:

"array-includes": {
  "version": "3.1.0",
  "resolved": "https://registry.npmjs.org/array-includes/-/array-includes-3.1.0.tgz",
  "integrity": "sha512-ONOEQoKrvXPKk7Su92Co0YMqYO32FfqJTzkKU9u2UpIXyYZIzLSvpdg4AwvSw4mSUW0czu6inK+zby6Oj6gDjQ==",
  "dev": true,
  "requires": {
    "define-properties": "^1.1.3",
    "es-abstract": "^1.17.0-next.0"
  },
  "dependencies": {
    "es-abstract": {
      "version": "1.17.0-next.1",
      "resolved": "https://registry.npmjs.org/es-abstract/-/es-abstract-1.17.0-next.1.tgz",

...

et

"array.prototype.find": {
  "version": "2.1.0",
  "resolved": "https://registry.npmjs.org/array.prototype.find/-/array.prototype.find-2.1.0.tgz",
  "integrity": "sha512-Wn41+K1yuO5p7wRZDl7890c3xvv5UBrfVXTVIe28rSQb6LS0fZMDrQB6PAcxQFRFy6vJTLDc3A2+3CjQdzVKRg==",
  "requires": {
    "define-properties": "^1.1.3",
    "es-abstract": "^1.13.0"
  }
},

Cela m'a amené à installer es-abstract 1.16.3 dans mes node_modules racine et 1.17.0-next.1 en tant que sous-dépendance de array-includes (entre autres).

Ayant changé ma configuration Jest moduleDirectories fait de mes node_modules racine le premier endroit de recherche. C'est ce que Jest docs dire sur cette option: Un tableau de noms de répertoires à rechercher récursive et activation de cette option remplace la valeur par défaut, qui se trouve être node_modules .

alors vérifiez votre configuration pour cette fonctionnalité:


0 commentaires

0
votes

C'est un problème avec la configuration Webpack ou Jest.

Les chemins absolus et relatifs peuvent tous deux être utilisés, mais sachez qu'ils se comporteront un peu différemment.

Un chemin relatif sera analysé de la même manière que Node scanne les node_modules, en parcourant le répertoire courant ainsi que ses ancêtres (c'est-à-dire ./node_modules, ../node_modules, etc.).

Avec un chemin absolu, il ne cherchera que dans le répertoire donné.

webpack.config.js

module.exports = {
  //...
  resolve: {
    modules: ['node_modules']
  }
};

Utiliser le chemin relatif pour node_modules


0 commentaires