Support cache of dependencies in setup-node.

[dmitry-shibanov]

Context

actions/setup-node is the 2nd most popular action in GitHub Actions. A lot of customers use it in conjunction with actions/cache to speed up dependencies installation.
See more examples on proper usage in actions/cache documentation.

Goals & Anti-Goals

Integration of caching functionality into actions/setup-node action will bring the following benefits for action users:

• Decrease the entry threshold for using the cache for Node.js dependencies and simplify initial configuration
• Simplify YAML pipelines because no need additional steps to enable caching
• More users will use cache for Node.js so more customers will have fast builds!

We will add support for NPM and Yarn dependencies caching.
As the first stage, we won't support custom locations for package-lock.json, yarn.lock files and action will work only when files are located in repository root.

We don't pursue the goal to provide wide customization of caching in scope of actions/setup-node action. The purpose of this integration is covering ~90% of basic use-cases. If user needs flexible customization, we should advice them to use actions/cache directly.

[dmitry-shibanov]

Summarized tables.

Express

Package Manager (Cache Status)	Ubuntu	Windows	macOS
npm (-)	0:05	0:23	0:13
npm (+)	0:05	0:19	0:10
yarn 1 (-)	0:06	0:24	0:12
yarn 1 (+)	0:05	0:21	0:10
yarn 2 (-)	0:14	0:18	0:15
yarn 2 (+)	0:12	0:16	0:13

Nest

Package Manager (Cache Status)	Ubuntu	Windows	macOS
npm (-)	1:02	1:40	1:41
npm (+)	0:55	1:25	1:17
yarn 1 (-)	0:43	3:44	5:27
yarn 1 (+)	0:26	3:21	4:01
yarn 2 (-)	2:01	2:30	3:01
yarn 2 (+)	0:30	0:48	0:45

Electron-react-boilerplate

Package Manager (Cache Status)	Ubuntu	Windows	macOS
npm (-)	0:50	1:24	2:15
npm (+)	0:44	1:10	1:30
yarn 1 (-)	1:05	2:52	1:43
yarn 1 (+)	0:34	2:32	1:19

Appcenter-cli

Package Manager (Cache Status)	Ubuntu	Windows	macOS
npm (-)	0:19	0:51	0:52
npm (+)	0:14	0:46	0:48
yarn 1 (-)	0:23	1:23	1:21
yarn 1 (+)	0:12	1:12	0:52
yarn 2 (-)	1:08	1:18	1:20
yarn 2 (+)	0:11	0:25	0:20

Summary

Package manager	Ubuntu	Windows	macOS
npm	-12%	-18%	-20%
yarn 1	-25%	-11.5%	-25%
yarn 2	-30%	-35%	-42%

Notes:

• Average win for npm - 10-20%
• Average win for yarn - 15-30%
• Results strongly depend on number of dependencies in project
  • For small projects (< 10 deps), cache doesn't make sense and sometimes can be even slower
  • For big projects (> 100 deps), cache brings good speed advantages
• Some npm dependencies have long post-install steps. For such deps we won't get much profit because we can't cache post-install steps somehow. Cache speed up only downloading of dependencies.

[leon]

Something that is rather common is deps placing things in the node_modules/.cache folder.
I think a good addition to the configuration would be a list of other directories that you also want to include.

Examples.
firebase emulator stores a cached version in

/home/runner/.cache/firebase/emulators

mongodb-memory-server also uses the cache

node_modules/.cache/mongodb-memory-server

so to speed things up it would be great to be able to pass these to the config.

this is what my actions/cache@v2 looked like.

      - name: Cache Yarn
        uses: actions/cache@v2
        id: cache-yarn
        with:
          path: |
            ~/cache
            ~/.cache
            !~/cache/exclude
            !~/.cache/exclude
            **/node_modules
          key: ${{ runner.os }}-node14-yarn-${{ hashFiles('**/yarn.lock') }}
          restore-keys: |
            ${{ runner.os }}-node14-yarn-

[maxim-lobanov]

Thank you for your proposal @leon .
We don't pursue the goal to provide wide customization of caching in scope of actions/setup-node action because it will lead to maintenance hell and duplicate logic of actions/cache.
The purpose of this integration is covering ~90% of basic use-cases from the box. For more flexible customization, we would suggest continue using actions/cache directly.