Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Can node_modules be cached if a Node.js version is supplied? #406

Closed
joneshf opened this issue Jan 15, 2022 · 4 comments
Closed

Can node_modules be cached if a Node.js version is supplied? #406

joneshf opened this issue Jan 15, 2022 · 4 comments
Labels
feature request New feature or request to improve the current logic

Comments

@joneshf
Copy link

joneshf commented Jan 15, 2022

Description:

As I understand the documentation about caching both in this repo and in the upstream actions/cache repo, the reason node_modules is not recommended to cache is because dependencies can break across versions of Node.js.

If the Node.js version changing is the only reason not to cache node_modules can this action take into account the node-version-file (or maybe even the node-version)? If it doesn't exist, don't cache the node_modules directory. If it does exist, cache the node_modules directory but use the value as part of the primaryKey:

const primaryKey = `node-cache-${platform}-${packageManager}-${fileHash}`;

Maybe as like:

const primaryKey = `node-cache-${platform}-${nodeVersionFileHash}-${packageManager}-${fileHash}`;

If the Node.js version changes, the cache should be invalidated and everything rebuilt. Which seems to address the concern the actions/cache repo points out (as I understand it).

Justification:

The current caching strategy doesn't provide a noticeable improvement for non-trivial projects. It'll shave a couple seconds off of a multiple minute build due to needing to download all of the node_modules directory. Ideally, by caching node_modules when it appears safe to do so, the download of node_modules shouldn't need to happen as frequently and caching can save minutes.

Are you willing to submit a PR?

Yes!

@joneshf joneshf added feature request New feature or request to improve the current logic needs triage labels Jan 15, 2022
@dmitry-shibanov
Copy link
Contributor

Hello @joneshf. Thank you for your report. For now we're not planing to change caching behaviour for the setup-node action. If you need to cache different path, the recommended solution will be using the actions/cache action.
For now I'm going to close the feature request.

@joneshf
Copy link
Author

joneshf commented Jan 17, 2022

Understood. Thanks for the explanation.

@GermanJablo
Copy link

For now we're not planing to change caching behaviour for the setup-node action.

May I know if that has changed and if not, what is the reason?
I offer to do the PR if it's a time problem :)

deining pushed a commit to deining/setup-node that referenced this issue Nov 9, 2023
* fix: re-stage files after pulling

This should fix an issue that prevented changes from being committed
when `git pull --rebase --autostash` used.

Issue actions#406

* chore: mark pre-commit hook as executable

* fix: detect conflicts after pull
@karlhorky
Copy link

karlhorky commented Nov 20, 2023

@dmitry-shibanov would also love to see this built in as an option to the actions/setup-node action, if there's any room for reconsideration for this feature request after a couple of years 👍

(more discussion about node_modules over in #304)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
feature request New feature or request to improve the current logic
Projects
None yet
Development

No branches or pull requests

4 participants