Skip to content
This repository was archived by the owner on Nov 4, 2024. It is now read-only.
This repository was archived by the owner on Nov 4, 2024. It is now read-only.

should one disable cache during development? #746

@dkebler

Description

@dkebler

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:

  1. Is it recommended to turn off the cache in development using the env variable to avoid these frustrations? or is there some better way.
  2. 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

Activity

changed the title [-]should one disable cache during develeopment?[/-] [+]should one disable cache during development?[/+] on Mar 11, 2019
jdalton

jdalton commented on Mar 11, 2019

@jdalton
Member

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

dkebler

dkebler commented on Mar 13, 2019

@dkebler
Author

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

jdalton commented on Mar 13, 2019

@jdalton
Member

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?

Disabling the cache disables the cache 🙃

dkebler

dkebler commented on Mar 14, 2019

@dkebler
Author

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

jdalton commented on Mar 14, 2019

@jdalton
Member

@dkebler

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.

ghost
jdalton

jdalton commented on Mar 23, 2019

@jdalton
Member

Thanks @indiescripter!

It looks like npm pack does change the mtime to Oct 26 01:15:00 1985.
I'll patch to account for this.

do .cache/esm files still get created anyway even if only for temporary purposes?

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 🎉

added 2 commits that reference this issue on Mar 23, 2019
b8e2f7b
376438c
ghost
dkebler

dkebler commented on Apr 18, 2019

@dkebler
Author

Disabling the cache disables the cache upside_down_face

"ESM_DISABLE_CACHE=true nodemon -r esm ./"

caches still being made. Docs do not indicate value for this env var.

jdalton

jdalton commented on Apr 18, 2019

@jdalton
Member

Any truthy value should do. See

dirty = !! parseJSON(getEnv("ESM_DISABLE_CACHE"))

12 remaining items

Loading
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

      Development

      No branches or pull requests

        Participants

        @jdalton@celeduc@michaelfig@dkebler

        Issue actions

          should one disable cache during development? · Issue #746 · standard-things/esm