|
|
|
@@ -1,6 +1,6 @@
|
|
|
|
## 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.
|
|
|
|
@@ -35,6 +35,25 @@ 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` contains a `packageManager` field set to npm (or devEngines.packageManager), automatic caching is enabled by default. Override this by setting `package-manager-cache: false`.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
```yaml
|
|
|
|
|
|
|
|
steps:
|
|
|
|
|
|
|
|
- uses: actions/checkout@v6
|
|
|
|
|
|
|
|
- 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.
|
|
|
|
|