Controlling cache dir with env variable

[tomasz-sodzawiczny]

Issue

In many cases it is useful to control the cache directory depending on the environment some tool/command is run in.

For example often in local development we want to keep the default ./node_modules/.cache/my-lib location but in CI/CD pipeline we want to put it in some place we can persist it between runs.

It would be good to have an unified way of controlling directory that with env variable.

Env variables seem to be a common way to do that, a lot of projects that use caches support it in similar way (e.g. yarn uses YARN_CACHE_FOLDER, npm - NPM_CACHE_LOCATION).

Possible solutions

Single variable for whole .cache dir

CACHE_DIR=/some/path will change the destination for all projects

Cons:

• no per-project granularity (might be useful to control e.g. what we're persisting between runs)
• CACHE_DIR is definitely a bad name (too general, 100% sure it's already used in many pipelines)
  • hard to name it in an understandable way

Separate variable for each project

When calling findCacheDir({name: 'foo'}) we would use FOO_CACHE_DIR.

Cons:

• name has to be generated (is name.toUpperCase() enough?)
• it will expose undocumented API to some libraries - might be confusing for library maintainers/developers who don't know about this feature

Every project does it separately

find-cache-dir doesn't handle the env variables, projects that want to use it handle it on their own.

Cons (?):

• has to be implemented manually on each project

(Suggested on cache-loader: https://github.com/webpack-contrib/cache-loader/pull/92)

[langri-sha]

This has already been asked for: https://github.com/avajs/find-cache-dir/issues/1 https://github.com/avajs/find-cache-dir/issues/9 https://github.com/avajs/find-cache-dir/issues/10.

But I'm really happy that more people are opening up issues. I hope this feature gets added, because even if I don't want to use find-cache-dir directly, some dependencies produce meaningful cache outputs that are combobulated with dependencies because of they depend on this package.

It means that in such cases we cannot store/restore our dependency and app caches in parallel, but in sequence. This adds to build times, which costs money and takes away from our developer productivity.

[b1rdex]

There are almost 3.5m of repositories that are (mostly indirectly) dependant on this package. See https://github.com/avajs/find-cache-dir/network/dependents?package_id=UGFja2FnZS0xNTY5NDYwMQ%3D%3D. And this number will only rise in the future because of such major adoptions like babel and eslint.

IMO there should be a way to globally control where the cache should be put.

Also, as @isaacs said 4 years ago (https://github.com/avajs/find-cache-dir/issues/1#issue-126079274), node_modules shouldn't be touched outside of npm. Nowadays, there is yarn and it's PnP feature (https://classic.yarnpkg.com/en/docs/pnp/) that is "removing" the need for the node_modules folder.

[isaacs]

Fwiw, the world has changed a bit in the last 4 years. ESM, babel, nyc, jest, lots of other dev tools have followed this pattern. I've been using ./node_modules/.cache/tap for caching files for node-tap. I was right to be concerned 4 years ago, but 4 years ago me would be wrong to stay concerned today.

I'd be happy to +1 an npm rfc to bless the .cache folder officially as a place for modules to stash stuff, as long as a package uses the same subfolder in node_modules/.cache as their package name.