-
Notifications
You must be signed in to change notification settings - Fork 29k
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
Modules loaded through --import
seem to use a separate ESM cache
#44583
Comments
Note that it is expected to change soon-ish, as the plan is to move the loaders to a separate thread. Do you expect them to share the same cache? If we move forward with the plan, loaders would definitely use their own cache. That being said, it looks like the same happen with mkdir repro && cd repro
echo 'import "./shared-dep.mjs";console.log("loaded loader.mjs");' > loader.mjs
echo 'console.log("loaded shared-dep.mjs");' > shared-dep.mjs
echo 'import "./loader.mjs";import "./shared-dep.mjs";console.log("loaded run.mjs");' > run.mjs
node --import ./loader.mjs run.mjs
cd .. && rm -r repro /cc @nodejs/loaders @MoLow |
--import
seem to use a separate ESM cache
My use case is that I am using the custom loader when running tests to enable module mocks. How this works is that the I currently work around the issue by assigning the |
By the way: where I would expect separate ESM caches, but where they currently seem to share a single one, is when running Unfortunately as far as I can see all test modules currently share the same ESM cache. |
@timmolendijk if you have a repro for running |
This comment was marked as off-topic.
This comment was marked as off-topic.
They definitely use different caches: there are 2 independent instances of ESMLoader, each of which instantiate their own Map. This is very much by design. Indeed once they are separated by thread boundaries (#44710) they will be further separated. |
@JakobJingleheimer that doesn't apply to |
It does: |
Interesting point @aduh95, I also would have expected |
Some related discussion (from August) in the OpenJS slack: https://openjs-foundation.slack.com/archives/C01810KG1EF/p1659692532627829 Maël Nison aduh95 cspotcode aduh95 cspotcode Geoffrey Booth Geoffrey Booth aduh95 Geoffrey Booth Geoffrey Booth aduh95 aduh95 Maël Nison Maël Nison |
Fixed by #44710 (not the OP, now that loaders are in a different thread, they definitely not share the user-land module cache. but |
Version
v18.8.0
Platform
Darwin Tims-MacBook-Pro.local 21.6.0 Darwin Kernel Version 21.6.0: Wed Aug 10 14:28:23 PDT 2022; root:xnu-8020.141.5~2/RELEASE_ARM64_T6000 arm64
Subsystem
ECMAScript modules
What steps will reproduce the bug?
When running the following command:
Given the following context:
The output is as follows:
Notice how the imports from
--experimental-loader ./loader.mjs
are reloaded once they are imported fromnode ./run.mjs
, while the two times thatshared-dep.mjs
is imported as a result of the latter triggers only a single load. This looks to me like we are dealing with two ESM caches here.How often does it reproduce? Is there a required condition?
Sharing modules between A & B when doing
node --experimental-loader A B
.What is the expected behavior?
What do you see instead?
Additional information
The two do share the same
global
.The text was updated successfully, but these errors were encountered: