In #13 it was proposed to not cache both package manager's global cache and node_modules but only one of them.
@simonihmig proposed to cache only package manager's global cache:
What it does not do however AFAIK is that it caches both the npm/yarn cache as well as node_modules itself (it does only the former). But what I am really not sure about is how useful caching both is. The former will already prevent fetching from the network I believe. And the examples given by @actions/cache also show only the former version of caching: https://github.com/actions/cache/blob/main/examples.md#node---yarn :man_shrugging:
@kategengler proposed to cache only node_modules:
In my experimentation, the best caching I've found was by caching node_modules/ See emberjs/ember.js#19098
I think additionally to what to cache we should discuss when to reuse the cache. It might be quicker to always reuse the same cache even if yarn.lock or package-log.json changes as installation is much faster if node_modules is prepopulated.
I fear we won't be able to answer these questions without benchmarks and some real world experience. Not sure if investing that time is worth the performance win to be honest. But maybe there are already good articles on that topic?
In #13 it was proposed to not cache both package manager's global cache and
node_modulesbut only one of them.@simonihmig proposed to cache only package manager's global cache:
@kategengler proposed to cache only node_modules:
I think additionally to what to cache we should discuss when to reuse the cache. It might be quicker to always reuse the same cache even if
yarn.lockorpackage-log.jsonchanges as installation is much faster ifnode_modulesis prepopulated.I fear we won't be able to answer these questions without benchmarks and some real world experience. Not sure if investing that time is worth the performance win to be honest. But maybe there are already good articles on that topic?