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.

We also had same problem. I created an issue for this https://github.com/ljharb/es-abstract/issues/83. You can get notification and solutions from there maybe. — slnkykrn, Dec 18 '19 at 07:53
We are also encountering the described issue. Haven't found any solution yet. We are also using a React 15.x version and Webpack 2.x due to it being a "legacy" project. I pretty much went through the same debugging process as OP and was able to find the "missing" files in the node_modules folder of es-abstract. I am clueless.. — noa-dev, Dec 18 '19 at 10:06
We are also using fixed versions to have no issues like that - one of them is a library called react-dates@10.1.1 <- which is a 3 year old release. UNFORTUNATELY React dates has a dependecy to "airbnb-prop-types": "^2.4.1" with a dynamic version -> airbnb-prop-types 2.15 latest release just happened few days ago which included the es-abstract@1.17.0-next.1 release — noa-dev, Dec 18 '19 at 10:25
since the library that added the dynamic version require seems to not be properly maintained any more (443 open issues and 70 open PRs) i will fork it and selfhost — noa-dev, Dec 18 '19 at 10:29
What “dynamic application require”? enzyme is fully maintained, as is airbnb-prop-types. This is a misconfiguration of webpack and nothing more. Please file github issues for these things. — LJHarb, Dec 18 '19 at 15:48
https://github.com/ljharb/es-abstract/issues/84#issuecomment-567634975 — Gabriel Ferrarini, Dec 19 '19 at 19:53
Just as a random note, we ended up working around this by temporarily pulling Enzyme to avoid the issue altogether. We are considering moving to Jest, though, which may give us an opportunity to try the custom module resolution below. Also, we should probably just look into upgrading Node. — wesley.fok, Dec 24 '19 at 19:49
Had the same issue. I solved it here https://stackoverflow.com/a/64895428/10944219 — tom, Nov 18 '20 at 14:51

ANIL PATEL · Answer 1 · 2020-11-19T13:18:48.993

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

score 1 · Answer 2 · answered Dec 20 '19 at 11:35

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.

score 0 · Answer 3 · answered Dec 19 '19 at 10:08

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.

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

3 Answers3