import(cjs) with query strings has odd behavior

[mysticatea]

• Version: 12.11.1
• Platform: Windows 10
• Subsystem: ES modules

From eslint/eslint#12333

Repro https://github.com/mysticatea/import-cjs-issue

Description

I tried to import packages without import cache. From the document, it looks I should use query strings.

    await import("x-esm") //→ Found as expected
    await import("./node_modules/x-esm/index.js?q=0") //→ Found and `x-esm` re-ran as expected
    await import("./node_modules/x-esm/index.js?q=1") //→ Found and `x-esm` re-ran as expected

x-esm is an ES module package. It worked as expected.

    const cjs = await import("x-cjs") //→ Found as expected
    const cjs0 = await import("./node_modules/x-cjs/index.js?q=0") //→ Found but `x-cjs` didn't re-run
    const cjs1 = await import("./node_modules/x-cjs/index.js?q=1") //→ Found but `x-cjs` didn't re-run
    console.log(cjs === cjs0, cjs === cjs1, cjs0 === cjs1) //→ all are false but `x-cjs` didn't run three times

x-cjs is a CJS package. The result was odd. The console.log() in x-cjs package ran only one time, but the returned values are different for each query string.

I found the entry of x-cjs in require.cache. However, the cache entry is odd as well. It's different from require("x-cjs"), the entry doesn't have parent property and the module.children of test.js is still empty.

Anyway, I tried to remove the cache entry.

    console.log("---- remove 'require.cache' ----")
    delete require.cache[require.resolve("x-cjs")]
    await import("x-cjs") //→ Found but `x-cjs` didn't re-run
    await import("./node_modules/x-cjs/index.js?q=0") //→ Found but `x-cjs` didn't re-run
    await import("./node_modules/x-cjs/index.js?q=1") //→ Found but `x-cjs` didn't re-run
    await import("./node_modules/x-cjs/index.js?q=2") //→ Found and `x-cjs` re-ran as expected
    await import("./node_modules/x-cjs/index.js?q=3") //→ Found but `x-cjs` didn't re-run

Cryptic. I guess this behavior is:

• import(cjs) has cache apart from require.cache.
• The import(cjs) cache is created from require.cache.
• It runs CJS package only if require.cache entry was not found.
• The import(cjs) cache is not removed even if require.cache entry deleted.

Therefore, I have to do the following steps if I want to import packages without cache.

1. Find the main file of the package because I cannot put query strings to the package name.

   const url = "file:" + require.resolve(packageName) + uniqueQueryString;

2. Import it.

   const ret = await import(url);

3. Delete require.cache entry.

   delete require.cache[require.resolve(packageName)];

Questions

1. Is it intentional behavior that import(cjs) creates incomplete require.cache entries?
2. If yes, is it intentional behavior that import(cjs) with query strings returns different objects for the same CJS package?

I'm guessing that import(cjs) should not create any require.cache entries, and import(cjs) with query strings re-runs CJS packages as same as ES packages.

[mysticatea]

This issue is still valid in Node.js 13.0.1.

[guybedford]

Here is how CJS modules are loaded into the ESM loader:

1. Whenever a CJS module is loaded via require(), it is injected at its path into the ESM loader (without any query string)
2. Whenever an CJS module is loaded from import, it calls out to the CJS loader, which then injects the module value back.

As a result: CommonJS modules loaded with query strings will not load their exports, AND query strings will not reload the module.

This is the way the design works unfortunately and it cannot really be changed. It was done this way because it was deemed important to "snapshot" CommonJS modules at their time of execution to inject them into the ESM loader.

The only way to allow the model this issue is asking for would be to remove that "snapshot" requirement, which I'm not sure is possible.

That said if it is possible - now would be the time to argue for it.

[aduh95]

Should this be closed as known limitation now that #35781 has landed?

[github-actions]

There has been no activity on this feature request for 5 months and it is unlikely to be implemented. It will be closed 6 months after the last non-automated comment.

For more information on how the project manages feature requests, please consult the feature request management document.

[github-actions]

There has been no activity on this feature request and it is being closed. If you feel closing this issue is not the right thing to do, please leave a comment.

For more information on how the project manages feature requests, please consult the feature request management document.