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

How to invalidate ES module cache #1399

Closed
mfidemraizer opened this issue Jul 27, 2018 · 8 comments
Closed

How to invalidate ES module cache #1399

mfidemraizer opened this issue Jul 27, 2018 · 8 comments

Comments

@mfidemraizer
Copy link

@mfidemraizer mfidemraizer commented Jul 27, 2018

  • 10.x:
  • Linux Mint 18.3:
  • runtime:

Hi!

ES modules docs state:

require.cache is not used by import. It has a separate cache.

Where's that separate cache? I need to invalidate it as it can be done in CommonJS modules for testing purposes.

How can I access that cache? Or, how can I completely invalidate the module cache?

Thank you in advance!

@devsnek

This comment has been minimized.

Copy link
Member

@devsnek devsnek commented Jul 27, 2018

the es module cache is designed to be immutable. we are working on hooks to allow mocking and such but raw access to the cache will never be available.

@mfidemraizer

This comment has been minimized.

Copy link
Author

@mfidemraizer mfidemraizer commented Jul 27, 2018

@devsnek

Oops! And does changing the file:// URI break the cache? I mean, I could add a random querystring parameter, since what I want to invalidate starts from a dynamic import.

In fact, I've implemented ES module mocking already but it fails to work in some scenarios because of caching:

const httpApiInitP = importWithMocks (
         '../../../../src/init.mjs',
         import.meta.url,
         [
            `../../../../../shared/src/cache/collectionOps.mjs`,
            `./mocks/collectionOpsMock.mjs`
         ]
      )

Also, does this WIP hooks are available in nightly builds? I really need an approach to mock modules or I'll need to face a very disturbing refactor in my project codebase.

@devsnek

This comment has been minimized.

Copy link
Member

@devsnek devsnek commented Jul 27, 2018

@mfidemraizer es modules are still in development so i wouldn't recommend migrating your project over to them just yet. Mocking/development are high on our list of things to support so don't worry about not having that ability in the future.

I could add a random querystring parameter, since what I want to invalidate starts from a dynamic import.

Yeah that's fine. We use the full URL internally (including query and hash) for the cache key.

@mfidemraizer

This comment has been minimized.

Copy link
Author

@mfidemraizer mfidemraizer commented Jul 27, 2018

@devsnek Nice (about both hooks with mocking and the thing of URLs).

My concern with randomizing URLs is I'm not breaking an entire dependency tree if I'm not mistaken: say there's a module A which mocks some import: I need to randomize URLs for all modules having the mocked module dependency too. Right?

@devsnek

This comment has been minimized.

Copy link
Member

@devsnek devsnek commented Jul 27, 2018

@mfidemraizer yeah nothing will depend or know about the module that got re-imported. again you will just have to wait for us to figure out how to safely expose the behaviour for this kinda stuff. you can follow along at https://github.com/nodejs/modules

@devsnek

This comment has been minimized.

Copy link
Member

@devsnek devsnek commented Jul 28, 2018

gonna close this -- please reopen if you feel your question hasn't been answered

@devsnek devsnek closed this Jul 28, 2018
@kimamula

This comment has been minimized.

Copy link

@kimamula kimamula commented Mar 10, 2019

We use the full URL internally (including query and hash) for the cache key.

Probably I am misunderstanding something but I cannot confirm this to be true.
I have tested the caching behavior of ESModules using Node.js v11.11.0 as follows.

// esm.mjs 
console.log('Hello, ESModules!');
// import-esm.mjs
import './esm?query=1';
import './esm?query=2';
$ node --experimental-modules import-esm
(node:40370) ExperimentalWarning: The ESM module loader is experimental.
Hello, ESModules!

As shown, Hello, ESModules! is logged only once, which indicates esm.mjs is loaded only once even if the module is imported twice with different queries.

@kimamula

This comment has been minimized.

Copy link

@kimamula kimamula commented May 2, 2019

Confirmed that the behavior I described above is fixed in Node.js v12.0.0.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
3 participants
You can’t perform that action at this time.