Webpack suddenly fails to compile due to "Module not found: Error: Can't resolve" errors

Question

As of yesterday afternoon, our Javascript unit test suite has started failing. None of the tests run and webpack reports a build failure after a string of Module not found errors. Here's our build stack:

Node 6.11.5 (yes I know, very old) Karma 1.7.1 Webpack 2.2.1 React 15.6.2

We run our unit tests using Karma. Most of the test suite involves React, so we use Webpack to build everything. To do this, we import our webpack config and then plug various values into the Karma webpack config.

Building the scripts directly using Webpack works fine, but when we try to run karma start we get a lot of these errors:

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

All of these issues seem to be tied to es-abstract, which we noticed had a new release yesterday (1.17.0-next.1). This is right around the time everything began failing. That said, the package seems to have downloaded and installed correctly:

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

And when I inspect the node_modules directory manually I can see all the files I would expect to see, based on a cursory examination of the es-abstract Github. I can't figure out why Webpack apparently can't see these files despite them being installed in the correct place. I also can't figure out why this would suddenly break as of yesterday, unless something was wrong with the es-abstract package. But if that's the case, no one's reported any issues to any of the affected projects (which include Enzyme and some of the ES shims) or to the es-abstract project itself. Also, looking at the CI builds for some of the affected projects, they all still seem to report passing tests.

We're at a loss of what to do. I've tried wiping out node_modules and npm installing from scratch, upgrading Node to the v8 LTS, downgrading Enzyme and the React adapter to try and pull in an older version of es-abstract (which doesn't work, their package.json files still ask for ^1.17.0-next.1, which makes no sense to me given some of these releases are a year old). Nothing works.

Answer 1

It's an issue with the Webpack or Jest configuration.

Absolute and relative paths can both be used, but be aware that they will behave a bit differently.

A relative path will be scanned similarly to how Node scans for node_modules, by looking through the current directory as well as its ancestors (i.e. ./node_modules, ../node_modules, and on).

With an absolute path, it will only search in the given directory.

webpack.config.js

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

Use relative path for node_modules

Answer 2

I had this issue and solved by fixing my modules resolution settings in Jest.

With the current state of things, my package-lock includes:

"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"
  }
},

and

"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",

...

This caused me to have es-abstract 1.16.3 installed in my root node_modules and 1.17.0-next.1 as a subdependency of array-includes (among others).

Having changed my Jest moduleDirectories config made my root node_modules the first lookup place. This is what Jest docs say about this option: An array of directory names to be searched recursively up and Setting this option will override the default, which happens to be node_modules.

so check your configuration for this feature:

• https://jestjs.io/docs/en/configuration#moduledirectories-arraystring for jest
• https://webpack.js.org/configuration/resolve/ for webpack.

Answer 3

I created an issue on the maintainers github repository https://github.com/ljharb/es-abstract/issues/84#issuecomment-567422831

Since we are encountering the exact same issue we went with an idea that was described by a comment. Running the webpack development build under productionflag. For us all source-map entries are kept and our development app is fully debugable. So we use that as a workaround.

If that ever breaks in future we will probably fork all the repositories that went with a semver range dependency and host it ourselves for our really outdated legacy repos.