Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

import(cjs) with query strings has odd behavior #29812

Closed
mysticatea opened this issue Oct 2, 2019 · 5 comments
Closed

import(cjs) with query strings has odd behavior #29812

mysticatea opened this issue Oct 2, 2019 · 5 comments
Labels
esm Issues and PRs related to the ECMAScript Modules implementation. feature request Issues that request new features to be added to Node.js. module Issues and PRs related to the module subsystem. stale

Comments

@mysticatea
Copy link

mysticatea commented Oct 2, 2019

  • 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.

@ZYSzys ZYSzys added the esm Issues and PRs related to the ECMAScript Modules implementation. label Oct 3, 2019
@mysticatea
Copy link
Author

This issue is still valid in Node.js 13.0.1.

@guybedford
Copy link
Contributor

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.

@guybedford guybedford added the feature request Issues that request new features to be added to Node.js. label Mar 12, 2020
@aduh95
Copy link
Contributor

aduh95 commented Mar 21, 2021

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

@DerekNonGeneric DerekNonGeneric added the module Issues and PRs related to the module subsystem. label Apr 2, 2021
@DerekNonGeneric DerekNonGeneric self-assigned this Apr 2, 2021
@github-actions
Copy link
Contributor

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
Copy link
Contributor

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
esm Issues and PRs related to the ECMAScript Modules implementation. feature request Issues that request new features to be added to Node.js. module Issues and PRs related to the module subsystem. stale
Projects
Development

No branches or pull requests

5 participants