actions/setup-node
1
0
Fork 0
mirror of https://github.com/actions/setup-node.git synced 2025-12-25 09:47:07 +00:00
Code Issues Projects Releases Packages Wiki Activity Actions

update documentation for lockfile

Browse source
This commit is contained in:
mahabaleshwars 2025-12-02 12:32:34 +05:30
parent b9b25d45f7
commit 4b33d362ab
2 changed files with 22 additions and 2 deletions
Download patch file Download diff file Expand all files Collapse all files

2
README.md
View file

@ -148,7 +148,7 @@ Since it will not be cached always, there is possibility of hitting rate limit w
### Checking in lockfiles ### Checking in lockfiles
It's **always** recommended to commit the lockfile of your package manager for security and performance reasons. For more information consult the "Working with lockfiles" section of the [Advanced usage](docs/advanced-usage.md#working-with-lockfiles) guide. It's **strongly recommended** to commit the lockfile of your package manager for security and performance reasons. For more information consult the "Working with lockfiles" section of the [Advanced usage](docs/advanced-usage.md#working-with-lockfiles) guide.
## Caching global packages data ## Caching global packages data

22
docs/advanced-usage.md
View file

@ -1,12 +1,14 @@
## Working with lockfiles ## Working with lockfiles
All supported package managers recommend that you **always** commit the lockfile, although implementations vary doing so generally provides the following benefits: Most supported package managers recommend that you **always** commit the lockfile, although implementations vary doing so generally provides the following benefits:
- Enables faster installation for CI and production environments, due to being able to skip package resolution. - Enables faster installation for CI and production environments, due to being able to skip package resolution.
- Describes a single representation of a dependency tree such that teammates, deployments, and continuous integration are guaranteed to install exactly the same dependencies. - Describes a single representation of a dependency tree such that teammates, deployments, and continuous integration are guaranteed to install exactly the same dependencies.
- Provides a facility for users to "time-travel" to previous states of `node_modules` without having to commit the directory itself. - Provides a facility for users to "time-travel" to previous states of `node_modules` without having to commit the directory itself.
- Facilitates greater visibility of tree changes through readable source control diffs. - Facilitates greater visibility of tree changes through readable source control diffs.
**However, for libraries, not using a lockfile may be preferable to ensure testing with the latest transitive dependencies. See the [Node.js Package Maintenance Working Group documentation on dependency management guidelines](https://github.com/nodejs/package-maintenance/blob/main/docs/dependency-management-guidelines.md#using-lockfiles) for a discussion of tradeoffs.**
In order to get the most out of using your lockfile on continuous integration follow the conventions outlined below for your respective package manager. In order to get the most out of using your lockfile on continuous integration follow the conventions outlined below for your respective package manager.
### NPM ### NPM
@ -35,6 +37,24 @@ Ensure that `pnpm-lock.yaml` is always committed, when on CI pass `--frozen-lock
- [Working with Git - Lockfiles](https://pnpm.io/git#lockfiles) - [Working with Git - Lockfiles](https://pnpm.io/git#lockfiles)
- [Documentation of `--frozen-lockfile` option](https://pnpm.io/cli/install#--frozen-lockfile) - [Documentation of `--frozen-lockfile` option](https://pnpm.io/cli/install#--frozen-lockfile)
### Running without a lockfile
If you choose not to use a lockfile, you must ensure that **caching is disabled**. The `cache` feature relies on the lockfile to generate a unique key for the cache entry.
To run without a lockfile:
1. Do not set the `cache` input.
2. If your `package.json` specifies a `packageManager` (which enables automatic caching in v5+), explicitly disable it:
```yaml
steps:
- uses: actions/checkout@v5
- uses: actions/setup-node@v6
with:
node-version: '24'
package-manager-cache: false # Explicitly disable caching if you don't have a lockfile
- run: npm install
- run: npm test
## Check latest version ## Check latest version
The `check-latest` flag defaults to `false`. When set to `false`, the action will first check the local cache for a semver match. If unable to find a specific version in the cache, the action will attempt to download a version of Node.js. It will pull LTS versions from [node-versions releases](https://github.com/actions/node-versions/releases) and on miss or failure will fall back to the previous behavior of downloading directly from [node dist](https://nodejs.org/dist/). Use the default or set `check-latest` to `false` if you prefer stability and if you want to ensure a specific version of Node.js is always used. The `check-latest` flag defaults to `false`. When set to `false`, the action will first check the local cache for a semver match. If unable to find a specific version in the cache, the action will attempt to download a version of Node.js. It will pull LTS versions from [node-versions releases](https://github.com/actions/node-versions/releases) and on miss or failure will fall back to the previous behavior of downloading directly from [node dist](https://nodejs.org/dist/). Use the default or set `check-latest` to `false` if you prefer stability and if you want to ensure a specific version of Node.js is always used.