You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository was archived by the owner on Nov 4, 2024. It is now read-only.
Found myself updating a package I'm working on in another project and then wondering why the new code (although there in the node_modules) is ignored only to find that the folder has a node_modules/esm cache in it as well. When I delete that then happily the new code is loaded instead of I assume the code that was in the cache.
So two questions:
Is it recommended to turn off the cache in development using the env variable to avoid these frustrations? or is there some better way.
What will be the issues in production when updating dependencies. Won't the same thing happen?
I suppose if you could elaborate a bit on the cache and it use/purpose I'd understand better the implications of use. I saw some other issues about invalidating the cache(s) is that something that should happen automagically on dependency updates? Thx
Our cache is generated by an mtime of the source + file path + loader config. If any one of them changes the old cache is discarded and a new entry is created. Do you know if an upgrade also updates the mtime of the files or if it preserves the original?
If it preserves the original that could be the source of the problem. If it's a common enough issue I can see about also adding the package version of the module to the cache hash.
This maybe be happening to me because when I am fixing an issue with an underlying package I use npm link (or an rsync if remote) to get the working package code in place. Seems like that would not invalidate the cache. Still in this case what file path does it use? the main from package json? Most of my packages use an index.js file for the main and load exported/imports from the actual source files. Would that not cause invalidation? So yea maybe package version is a good idea to add in as well although sometimes in development I force push on the same version for small bug fixes :-
So per my question 1. If I set the env variable I won't have any of these issues. No caches, every run starts from scratch?
This maybe be happening to me because when I am fixing an issue with an underlying package I use npm link (or an rsync if remote) to get the working package code in place.
If you could create a small repro repo of this scenario I can investigate and possibly add it to our test suite.
So per my question 1. If I set the env variable I won't have any of these issues. No caches, every run starts from scratch?
I'm trying to complete a project but this issue is important to me as well as esm sooo I will get around to making you a repo. Otherwise if it's not a big deal to invalidate the cache by package version (including a patch) I'd do it for no other reason than to cover all bases.
I am a bit confused about where the cache(s) are made. It is only supposed to be in the main node_modules/.cache/esm? Or does esm create one for each dependency? because that's what I notice. It's the later that causes the problem.
i.e. node-program-root/node_modules/mylibpackage/node_modules/.cache/esm
If I do an npm link mylibpackage then I have to delete that corresponding cache or I have the problem.
I am a bit confused about where the cache(s) are made. It is only supposed to be in the main node_modules/.cache/esm?
Caches are made at package boundaries where esm is used unless otherwise customized by the cache option. So there can be multiple .cache folders. Caches are based on the resolved filenames.
Welp, touching files broke people (#771) so I had to revert that. Looks like for your scenario disabling the cache with the environment variable or through config is the way to go 😄
Activity
[-]should one disable cache during develeopment?[/-][+]should one disable cache during development?[/+]jdalton commentedon Mar 11, 2019
Hi @dkebler!
Our cache is generated by an
mtime
of the source + file path + loader config. If any one of them changes the old cache is discarded and a new entry is created. Do you know if an upgrade also updates themtime
of the files or if it preserves the original?If it preserves the original that could be the source of the problem. If it's a common enough issue I can see about also adding the package version of the module to the cache hash.
dkebler commentedon Mar 13, 2019
This maybe be happening to me because when I am fixing an issue with an underlying package I use npm link (or an rsync if remote) to get the working package code in place. Seems like that would not invalidate the cache. Still in this case what file path does it use? the main from package json? Most of my packages use an index.js file for the main and load exported/imports from the actual source files. Would that not cause invalidation? So yea maybe package version is a good idea to add in as well although sometimes in development I force push on the same version for small bug fixes :-
So per my question 1. If I set the env variable I won't have any of these issues. No caches, every run starts from scratch?
jdalton commentedon Mar 13, 2019
If you could create a small repro repo of this scenario I can investigate and possibly add it to our test suite.
Disabling the cache disables the cache 🙃
dkebler commentedon Mar 14, 2019
I'm trying to complete a project but this issue is important to me as well as
esm
sooo I will get around to making you a repo. Otherwise if it's not a big deal to invalidate the cache by package version (including a patch) I'd do it for no other reason than to cover all bases.I am a bit confused about where the cache(s) are made. It is only supposed to be in the main node_modules/.cache/esm? Or does esm create one for each dependency? because that's what I notice. It's the later that causes the problem.
i.e.
node-program-root/node_modules/mylibpackage/node_modules/.cache/esm
If I do an
npm link mylibpackage
then I have to delete that corresponding cache or I have the problem.jdalton commentedon Mar 14, 2019
@dkebler
Caches are made at package boundaries where
esm
is used unless otherwise customized by thecache
option. So there can be multiple.cache
folders. Caches are based on the resolved filenames.jdalton commentedon Mar 23, 2019
Thanks @indiescripter!
It looks like
npm pack
does change themtime
toOct 26 01:15:00 1985
.I'll patch to account for this.
Nope.
Update:
Patches 51d31ef, 0da1bf4;
Update:
esm
v3.2.21 is released 🎉Update:
Welp, touching files broke people (#771) so I had to revert that. Looks like for your scenario disabling the cache with the environment variable or through config is the way to go 😄
Update:
esm
v3.2.22 is released 🎉Switch from using mtime to ctime for cache validation. [closes #746]
Revert "Switch from using mtime to ctime for cache validation. [closes …
dkebler commentedon Apr 18, 2019
"ESM_DISABLE_CACHE=true nodemon -r esm ./"
caches still being made. Docs do not indicate value for this env var.
jdalton commentedon Apr 18, 2019
Any truthy value should do. See
esm/src/caching-compiler.js
Line 185 in 91a154b
12 remaining items