actions/setup-node
11
0
Fork 0
mirror of https://github.com/actions/setup-node.git synced 2026-05-23 21:01:54 +00:00
Code Activity Actions

docs: fix language, casing, and formatting across markdown files

Browse source
This commit is contained in:
Kranthi Poturaju 2026-05-06 17:49:09 +05:30
parent 670825a89d
commit 05e89da72d
8 changed files with 56 additions and 56 deletions
Download patch file Download diff file Expand all files Collapse all files

16
docs/adrs/0000-caching-dependencies.md
View file

@ -3,11 +3,11 @@ Date: 2021-05-21
Status: Accepted
# Context
## Context
`actions/setup-node` is the 2nd most popular action in GitHub Actions. A lot of customers use it in conjunction with [actions/cache](https://github.com/actions/cache) to speed up dependencies installation.
See more examples on proper usage in [actions/cache documentation](https://github.com/actions/cache/blob/main/examples.md#node---npm).
# Goals & Anti-Goals
## 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
@ -16,23 +16,23 @@ Integration of caching functionality into `actions/setup-node` action will bring
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.
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 a user needs flexible customization, we should advise them to use `actions/cache` directly.
# Decision
## Decision
- Add `cache` input parameter to `actions/setup-node`. For now, input will accept the following values:
- `npm` - enable caching for npm dependencies
- `yarn` - enable caching for yarn dependencies
- `''` - disable caching (default value)
- Cache feature will be disabled by default to make sure that we don't break existing customers. We will consider enabling cache by default in next major release (`v3`)
- Action will try to search `package-lock.json` or `yarn.lock` (npm 7.x supports `yarn.lock` files) files in the repository root and throw error if no one is found
- The hash of found file will be used as cache key (the same approach like [actions/cache](https://github.com/actions/cache/blob/main/examples.md#node---npm) recommends)
- Action will try to search `package-lock.json` or `yarn.lock` (npm 7.x supports `yarn.lock` files) files in the repository root and throw an error if none is found
- The hash of the found file will be used as cache key (the same approach as [actions/cache](https://github.com/actions/cache/blob/main/examples.md#node---npm) recommends)
- The following key cache will be used `${{ runner.os }}-npm-${{ hashFiles('<package-lock-path>') }}`
- Action will cache global cache:
- Npm (retrieved via `npm config get cache`)
- Yarn 1 (retrieved via `yarn cache dir`)
- Yarn 2 (retrieved via `yarn config get cacheFolder`)
# Example of real use-cases
## Example of real use cases
Npm package manager:
```yml
steps:
@ -53,7 +53,7 @@ steps:
cache: yarn
```
# Release process
## Release process
As soon as functionality is implemented, we will release minor update of action. No need to bump major version since there are no breaking changes for existing users.
After that, we will update [starter-workflows](https://github.com/actions/starter-workflows/blob/main/ci/node.js.yml) and [GitHub Action documentation](https://docs.github.com/en/actions/guides/building-and-testing-nodejs#example-caching-dependencies).

12
docs/adrs/0001-support-caching-deps-for-monorepos.md
View file

@ -1,10 +1,10 @@
# 0. Support caching dependencies for mono repos
# 1. Support caching dependencies for mono repos
Date: 2021-07-13
Status: Proposed
## Context
Currently, `actions/setup-node` supports caching dependencies for Npm and Yarn package managers.
Currently, `actions/setup-node` supports caching dependencies for npm and Yarn package managers.
For the first iteration, we have decided to not support cases where `package-lock.json` / `yarn.lock` are located outside of repository root.
Current implementation searches the following file patterns in the repository root: `package-lock.json`, `yarn.lock` (in order of resolving priorities)
@ -13,10 +13,10 @@ We would like to revisit this decision and add customization for dependencies lo
## Proposal
We have the following options:
1. Allow to specify directory where `package-lock.json` or `yarn.lock` are located
2. Allow to specify path to the dependencies lock file (including directory path and filename)
1. Allow specifying a directory where `package-lock.json` or `yarn.lock` are located
2. Allow specifying a path to the dependency lock file (including directory path and filename)
The second option looks more generic because it allows to:
The second option looks more generic because it allows you to:
- specify multiple dependencies files using file patterns like `**/package-lock.json` ([one of recommended approaches in actions/cache](https://github.com/actions/cache/blob/main/examples.md#macos-and-ubuntu))
- specify custom dependencies files like `src/npm-shrinkwrap.json`
- change default resolving priority if both `yarn.lock` and `package-lock.json` exist in repository
@ -27,7 +27,7 @@ Add `cache-dependency-path` input that will accept path (relative to repository
If provided path contains wildcards, the action will search all matching files and calculate common hash like `${{ hashFiles('**/package-lock.json') }}` YAML construction does.
The hash of provided matched files will be used as a part of cache key.
Yaml examples:
YAML examples:
```yml
steps:
- uses: actions/checkout@v2

18
docs/advanced-usage.md
View file

@ -11,7 +11,7 @@ In order to get the most out of using your lockfile on continuous integration fo
### NPM
Ensure that `package-lock.json` is always committed, use `npm ci` instead of `npm install` when installing packages.
Ensure that `package-lock.json` is always committed; use `npm ci` instead of `npm install` when installing packages.
**See also:**
- [Documentation of `package-lock.json`](https://docs.npmjs.com/cli/v8/configuring-npm/package-lock-json)
@ -29,7 +29,7 @@ To ensure that `yarn.lock` is always committed, use `yarn install --immutable` w
### PNPM
Ensure that `pnpm-lock.yaml` is always committed, when on CI pass `--frozen-lockfile` to `pnpm install` when installing packages.
Ensure that `pnpm-lock.yaml` is always committed; when on CI, pass `--frozen-lockfile` to `pnpm install` when installing packages.
**See also:**
- [Working with Git - Lockfiles](https://pnpm.io/git#lockfiles)
@ -58,7 +58,7 @@ steps:
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.
If `check-latest` is set to `true`, the action first checks if the cached version is the latest one. If the locally cached version is not the most up-to-date, a version of Node.js will then be downloaded. Set `check-latest` to `true` it you want the most up-to-date version of Node.js to always be used.
If `check-latest` is set to `true`, the action first checks if the cached version is the latest one. If the locally cached version is not the most up-to-date, a version of Node.js will then be downloaded. Set `check-latest` to `true` if you want the most up-to-date version of Node.js to always be used.
> Setting `check-latest` to `true` has performance implications as downloading versions of Node is slower than using cached versions.
@ -240,7 +240,7 @@ jobs:
## RC versions
You can use specify a rc version to download it from https://nodejs.org/download/rc.
You can use specify a RC version to download it from https://nodejs.org/download/rc.
```yaml
jobs:
@ -259,7 +259,7 @@ jobs:
**Note:** Unlike nightly versions, which support version range specifiers, you must specify the exact version for a release candidate: `24.0.0-rc.4`.
## Caching packages data
The action follows [actions/cache](https://github.com/actions/cache/blob/main/examples.md#node---npm) guidelines, and caches global cache on the machine instead of `node_modules`, so cache can be reused between different Node.js versions.
The action follows [actions/cache](https://github.com/actions/cache/blob/main/examples.md#node---npm) guidelines and caches the global cache on the machine instead of `node_modules`, so the cache can be reused between different Node.js versions.
**Caching yarn dependencies:**
Yarn caching handles both Yarn Classic (v1) and Yarn Berry (v2, v3, v4+).
@ -332,7 +332,7 @@ steps:
**Restore-Only Cache**
```yaml
## In some workflows, you may want to restore a cache without saving it. This can help reduce cache writes and storage usage in workflows that only need to read from cache
## In some workflows, you may want to restore a cache without saving it. This can help reduce cache writes and storage usage in workflows that only need to read from cache.
jobs:
build:
runs-on: ubuntu-latest
@ -384,7 +384,7 @@ jobs:
name: Node ${{ matrix.node_version }} - ${{ matrix.architecture }} on ${{ matrix.os }}
steps:
- uses: actions/checkout@v6
- name: Setup node
- name: Setup Node.js
uses: actions/setup-node@v6
with:
node-version: ${{ matrix.node_version }}
@ -449,8 +449,8 @@ steps:
# `npm rebuild` will run all those post-install scripts for us.
- run: npm rebuild && npm run prepare --if-present
```
### Yarn2 configuration
Yarn2 ignores both .npmrc and .yarnrc files created by the action, so before installing dependencies from the private repo it is necessary either to create or to modify existing yarnrc.yml file with `yarn config set` commands.
### Yarn 2 configuration
Yarn 2 ignores both `.npmrc` and `.yarnrc` files created by the action, so before installing dependencies from the private repo it is necessary either to create or to modify an existing `yarnrc.yml` file with `yarn config set` commands.
Below you can find a sample "Setup .yarnrc.yml" step, that is going to allow you to configure a private GitHub registry for 'my-org' organisation.

28
docs/contributors.md
View file

@ -6,13 +6,13 @@ We have prepared a short guide so that the process of making your contribution i
## How can I contribute...
* [Contribute Documentation:green_book:](#contribute-documentation)
* [Contribute Documentation :green_book:](#contribute-documentation)
* [Contribute Code :computer:](#contribute-code)
* [Provide Support on Issues:pencil:](#provide-support-on-issues)
* [Provide Support on Issues :pencil:](#provide-support-on-issues)
* [Review Pull Requests:mag:](#review-pull-requests)
* [Review Pull Requests :mag:](#review-pull-requests)
## Contribute documentation
@ -22,10 +22,10 @@ Documentation contributions of any size are welcome! Feel free to contribute eve
**How to contribute:**
Pull requests are the easiest way to contribute changes to git repos at GitHub. They are the preferred contribution method, as they offer a convenient way of commenting and amending the proposed changes.
Pull requests are the easiest way to contribute changes to repositories on GitHub. They are the preferred contribution method, as they offer a convenient way of commenting and amending the proposed changes.
- Please check that no one else has already created a pull request with these or similar changes
- Use a "feature branch" for your changes. That separates the changes in the pull request from your other changes and makes it easy to edit/amend commits in the pull request
- Use a "feature branch" for your changes. That separates the changes in the pull request from your other changes and makes it easy to edit/amend commits in the pull request
- Make sure your changes are formatted properly and consistently with the rest of the documentation
- Re-read what you wrote, and run a spellchecker on it to make sure you didn't miss anything
- If your pull request is connected to an open issue, please, leave a link to this issue in the `Related issue:` section
@ -48,11 +48,11 @@ The main difference between code contributions and documentation contributions i
**How to contribute:**
Pull requests are the easiest way to contribute changes to git repos at GitHub. They are the preferred contribution method, as they offer a convenient way of commenting and amending the proposed changes.
Pull requests are the easiest way to contribute changes to repositories on GitHub. They are the preferred contribution method, as they offer a convenient way of commenting and amending the proposed changes.
- Please check that no one else has already created a pull request with these or similar changes
- Use a "feature branch" for your changes. That separates the changes in the pull request from your other changes and makes it easy to edit/amend commits in the pull request
- **Run `pre-checkin` script to format, lint, build and test changes**
- **Run `pre-checkin` script to format, lint, build and test changes**
- Make sure your changes are well formatted and that all tests are passing
- If your pull request is connected to an open issue, please, leave a link to this issue in the `Related issue:` section
- If you later need to add new commits to the pull request, you can simply commit the changes to the local branch and then push them. The pull request gets automatically updated
@ -62,15 +62,15 @@ Pull requests are the easiest way to contribute changes to git repos at GitHub.
- To implement new features or fix bugs, you need to make changes to the `.ts` files, which are located in the `src` folder
- To comply with the code style, **you need to run the `format` script**
- To lint the code, **you need to run the `lint:fix` script**
- To transpile source code to `javascript` we use [NCC](https://github.com/vercel/ncc). **It is very important to run the `build` script after making changes**, otherwise your changes will not get into the final `javascript` build
- To transpile source code to JavaScript we use [NCC](https://github.com/vercel/ncc). **It is very important to run the `build` script after making changes**, otherwise your changes will not get into the final JavaScript build
- You can also start formatting, building code, and testing with a single `pre-checkin` command
**Learn more about how to implement tests:**
Adding or changing tests is an integral part of making a change to the code.
Adding or changing tests is an integral part of making a change to the code.
Unit tests are in the `__tests__` folder, and end-to-end tests are in the `workflows` folder, particularly in the [versions.yml](https://github.com/actions/setup-node/blob/main/.github/workflows/versions.yml) and [e2e-cache.yml](https://github.com/actions/setup-node/blob/main/.github/workflows/e2e-cache.yml) files.
- The contributor can add various types of tests (like unit tests or end-to-end tests), which, in his opinion, will be necessary and sufficient for testing new or changed functionality
- The contributor can add various types of tests (like unit tests or end-to-end tests), which, in their opinion, will be necessary and sufficient for testing new or changed functionality
- Tests should cover a successful execution, as well as some edge cases and possible errors
- As already mentioned, pull requests without tests will be considered more carefully by maintainers. If you are sure that in this situation the tests are not needed or cannot be implemented with a commensurate effort - please add this clarification message to your pull request
@ -78,7 +78,7 @@ Unit tests are in the `__tests__` folder, and end-to-end tests are in the `workf
- CI will start automatically with some checks. Wait until the end of the execution and make sure that all checks passed successfully. If some checks fail, you can open them one by one, try to find the reason for failing and make changes to your code to resolve the problem
- Maintainers will review your pull request
- If a maintainer requests changes, first of all, try to think about his request critically and only after that implement and request another review
- If a maintainer requests changes, first of all, try to think about their request critically and only after that implement and request another review
- If your PR gets accepted, it will soon be merged into the main branch. But your contribution will take effect only after the release of a new version of the action and updating the major tag
> Sometimes maintainers reject pull requests and that's ok! Usually, along with rejection, we supply the reason for it. Nonetheless, we still really appreciate you taking the time to do it, and we don't take that lightly :heart:
@ -89,7 +89,7 @@ Helping out other users with their questions is an awesome way of contributing t
**To help other folks out with their questions:**
- Go to the [issue tracker](https://github.com/actions/setup-node/issues)
- Read through the list until you find something that you're familiar enough with to answer to
- Read through the list until you find something that you're familiar enough with to answer
- Respond to the issue with whatever details are needed to clarify the question, or get more details about what's going on
- Once the discussion wraps up and things are clarified, ask the original issue filer (or a maintainer) to close it for you
@ -105,12 +105,12 @@ Helping out other users with their questions is an awesome way of contributing t
## Review pull requests
Another great way to contribute is to review pull request. Please, be extra kind: people who submit code/doc contributions are putting themselves in a pretty vulnerable position, and have put time and care into what they've done (even if that's not obvious to you!) Please, always respond with respect, and be understanding, but don't feel like you need to sacrifice your standards for their sake, either.
Another great way to contribute is to review pull requests. Please be extra kind: people who submit code/doc contributions are putting themselves in a pretty vulnerable position, and have put time and care into what they've done (even if that's not obvious to you!) Please always respond with respect, and be understanding, but don't feel like you need to sacrifice your standards for their sake, either.
**How to review:**
- Go to the [pull requests](https://github.com/actions/setup-node/pulls)
- Make sure you're familiar with the code or documentation is updated, unless it's a minor change (spellchecking, minor formatting, etc.)
- Make sure you're familiar with the code or documentation being updated, unless it's a minor change (spellchecking, minor formatting, etc.)
- Review changes using the GitHub functionality. You can ask a clarifying question, point out an error or suggest an alternative.
> Note: You may ask for minor changes - "nitpicks", but consider whether they are real blockers to merging or not
- Submit your review, which may include comments, an approval, or a changes request