resolve: Error "ENOENT: no such file or directory, open '../../is-core-module/core.json"

Hello @ljharb!

Have this error in last resolve package version - ENOENT: no such file or directory, open '../../is-core-module/core.json

This change is breaking change for bundlers - https://github.com/browserify/resolve/commit/122bb64be2f4fcf927fd264d4b2c9ea622611c58, because bundler can’t process this require anymore.

Our case - we using webpack for server code (SSR application)

May I ask you to revert this change?

About this issue

  • Original URL
  • State: closed
  • Created a year ago
  • Reactions: 4
  • Comments: 20 (8 by maintainers)

Commits related to this issue

Most upvoted comments

For us it’s generating the following in webpack:

var data = JSON.parse(String(fs.readFileSync(path.join(path.dirname(/*require.resolve*/(91928)), 'core.json'))));

This obviously breaks because dirname won’t take a number argument.

Ah, thanks for the heads up on that,

Hi all – appreciate your thought on this issue. I see there hasn’t been a lot of activity and wanted to see if there feels like a viable path forward for v1. Although v1.22.2 is currently marked as latest, I’m hitting issues with v1.22.3 continuing to get pulled into my app. I can’t quite tell why – it may be some kind of transitive dependency that is still referencing ^v1.22.3. For what it’s worth, I’m using Yarn as the package manager. I’m curious if there’s any appetite to publish out a v1.22.4 which rolls back the change introduced in v1.22.3. For additional context, I’m hitting the problem from pulling in @opentelemetry/instrumentation which has a transitive dependency on resolve by way of require-in-the-middle.

Maybe caused by eslint-plugin-import. There is a release with eslint-plugin-import about 5 days ago,and they bumped version of resolve on Apr 15 (import-js/eslint-plugin-import@261ee3a).

As it happens,eslint-plugin-import has no release from Apr until 5 days ago,so they didn’t receive bug report of resolve until recent days.🤣

see import-js/eslint-plugin-import#2846

Ah, thanks for the heads up on that 👍

In case anyone else lands here that is using Yarn… TIL you can use selective dependency resolutions to pin v1.22.2. There’s a disclaimer that nested packages may not work properly, but I am seeing success with this so far 😄

Also, appreciate the quick reply @ljharb! Still definitely interested in the v1.22.4 publish when you have an opportunity. That’ll allow me to avoid the awkward pinning of the version 🙏

Hi all – appreciate your thought on this issue. I see there hasn’t been a lot of activity and wanted to see if there feels like a viable path forward for v1.

Although v1.22.2 is currently marked as latest, I’m hitting issues with v1.22.3 continuing to get pulled into my app. I can’t quite tell why – it may be some kind of transitive dependency that is still referencing ^v1.22.3. For what it’s worth, I’m using Yarn as the package manager.

I’m curious if there’s any appetite to publish out a v1.22.4 which rolls back the change introduced in v1.22.3.

For additional context, I’m hitting the problem from pulling in @opentelemetry/instrumentation which has a transitive dependency on resolve by way of require-in-the-middle.

Maybe caused by eslint-plugin-import. There is a release with eslint-plugin-import about 5 days ago,and they bumped version of resolve on Apr 15 (https://github.com/import-js/eslint-plugin-import/commit/261ee3aa7666edb0131e08db3d3d3428b013df42).

As it happens,eslint-plugin-import has no release from Apr until 5 days ago,so they didn’t receive bug report of resolve until recent days.🤣

see https://github.com/import-js/eslint-plugin-import/issues/2846

Yes, that seems like a reasonable thing to do given the length of time it’s taken to figure this out. I’m traveling right now, but will do that at the first opportunity.

We have the same issue and we also use webpack.