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

[SuperOleg39]

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 - 122bb64, 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?

[ljharb]

The core.js import is deprecated; you should be using is-core-module directly. That said, I’ll see what i can do.

[SuperOleg39]

Hmm looks like 7c26483 has never been published?

[SuperOleg39]

var async = require('./lib/async');
async.core = require('./lib/core');
async.isCore = require('./lib/is-core');
async.sync = require('./lib/sync');

module.exports = async;

It is code from library entry point (latest published version), webpack trying to process all imports here

[ljharb]

yeah, good call.

7c26483 is part of the v2 prerelease; v1 is managed on a separate branch.

[ljharb]

tbh tho I'm surprised webpack wouldn't be able to see the fs.readFileSync call and inline the file's contents.

[oksankaa]

We have the same issue and we also use webpack.

[ljharb]

@oksankaa you're also bundling on the server?

[SuperOleg39]

tbh tho I'm surprised webpack wouldn't be able to see the fs.readFileSync call and inline the file's contents.

It is quite impossible)
Popular bundlers have support for import/require with dynamic paths, but it is very limited by bunch of reasons

[oksankaa]

@oksankaa you're also bundling on the server?

yes

[foolzhang]

[JKapitein]

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.

[trentm]

@ljharb Do you intend to keep [email protected] using var data = require('./core.json');? (I'm inferring that was the intent, at least for the short term, by the "latest" dist-tag having moved to '1.22.2'.)

I'm currently maintaining require-in-the-middle and will try to get it to work with bundlers. I haven't looked at the [email protected] pre-releases yet.

[ljharb]

@trentm tbh I'm not sure yet. Keeping it that way means the data will be out of date between releases of resolve, and avoiding that (deferring it to is-core-module) was the goal.

[trentm]

One option would be to have a release of is-core-module with an export for "core.json":

diff --git a/package.json b/package.json
index 62bb065..078f73d 100644
--- a/package.json
+++ b/package.json
@@ -6,6 +6,7 @@
        "sideEffects": false,
        "exports": {
                ".": "./index.js",
+               "./core.json": "./core.json",
                "./package.json": "./package.json"
        },
        "scripts": {

then in [email protected] one could do:

var data = require('is-core-module/core.json');

---

However, I could understand if you don't want to do that (it adds API surface area to is-core-module) and just wanted to move forward with [email protected].

If/when you release a version of [email protected], and as long as it still supports node >=8.6.0, I can update require-in-the-middle to use resolve and is-core-module as needed.

Thanks for maintaining these modules.

[ljharb]

You're exactly right, and I want very much not to add to the API surface area of is-core-module.

resolve already has v2 prereleases, and I'd encourage you to use it! (and will support down to node 0.4 for the foreseeable future)

That said, I still need to figure out a fix for this in v1, and the current options, as you've accurately described, are:

1. do nothing, allow resolve v1 to be out of date between an is-core-module publish until the next v1 publish
2. add core.json to is-core-module
3. build some kind of complex multiple-file solution with the "browser" field, so that node uses readFileSync and browsers use require, meaning that a bundler that uses require but still respects "exports" would have the problem in the first bullet point

and none of those options are pleasant.

[schmalzs]

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.

[ljharb]

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.

[EAGzzyCSL]

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

[schmalzs]

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 🙏

[ljharb]

v1.22.4 is published; this can now be closed.

I still don't want to do inspect-js/is-core-module#14, but without that, I'm not sure how to keep core.json dynamically up to date with is-core-module while still supporting bundlers.