Clarify caching of npm / Yarn / pnpm dependencies

I was excited to see the blog post GitHub Actions: Setup-node now supports dependency caching. However, it’s not clear to me what this caching actually means. From the README:

<div type='discussions-op-text'>

^README.md

Caching yarn dependencies:

steps:
- uses: actions/checkout@v2
- uses: actions/setup-node@v2
  with:
    node-version: '14'
    cache: 'yarn'
- run: yarn install
- run: yarn test

Yarn caching handles both yarn versions: 1 or 2.

</div>

Caching can mean many things when it comes to Yarn 2, for example, these questions come to mind:

• Is the node_modules folder cached?
• When Yarn runs in the PnP mode, is .yarn/cache cached instead?
• Or is it the local cache of downloaded tarballs (~/.cache/yarn) that is cached?
• How is the caching done? Is it a local filesystem that is re-attached for future runs of the job or is the “slow” approach of @actions/cache that just uploads / downloads files to some S3-like blob storage? (I think we tested it and it wasn’t even faster than downloading dependencies from registry.npmjs.com over and over.)

Some clarifications would be appreciated 🙏.

[maxim-lobanov]

@borekb makes sense to me. Let me think how we can improve readme

@dominikg , since we cache “global cache” instead “node_modules”, Node.js version doesn’t matter and cache is identical. This way we cache only “download” step for packages and not “install” step. It is how actions/cache recommends.

The caching results of “post-install” scripts is not recommended because they can have side affects (change anything on machine outside of “node_modules” folder) or produce different results based on VM state (Image version on VM is updated every week and if result of some scripts depend on machine state, build can be broken after machine update)

[dmitry-shibanov]

Hello @akd-io. You’re right. It does not cache node_modules directory. Action uses npm config get cache to get global cache directory where all dependencies are cached. I think we can accept this pull request because as it was mentioned not everyone can have committed package-lock.json.

Hello @sandstrom. As I checked, the default branch cache is available to other branches in setup-node. Could you please create the separate issue and provide repro steps. I can suppose that on branches you change lock files, that’s why action can’t get previous primary key.

For now I’m closing the issue. If you have any other question feel free to ping me in the thread or create separate issue.