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

.github/ISSUE_TEMPLATE/bug_report.md

@@ -8,7 +8,7 @@ assignees: ''
 ---
 
 <!--- Please direct any generic questions related to actions to our support community forum at https://github.community/c/code-to-cloud/github-actions/41 --->
-<!--- Before opening up a new bug report, please make sure to check for similar existing issues -->
+<!--- Before opening up a new bug report, please make sure to check for similar existing issues --->
 
 **Description:**
 A clear and concise description of what the bug is.

CODE_OF_CONDUCT.md

@@ -68,9 +68,9 @@ members of the project's leadership.
 ## Attribution
 
 This Code of Conduct is adapted from the [Contributor Covenant][homepage], version 1.4,
-available at https://www.contributor-covenant.org/version/1/4/code-of-conduct.html
+available at [https://www.contributor-covenant.org/version/1/4/code-of-conduct.html](https://www.contributor-covenant.org/version/1/4/code-of-conduct.html)
 
 [homepage]: https://www.contributor-covenant.org
 
 For answers to common questions about this code of conduct, see
-https://www.contributor-covenant.org/faq
+[https://www.contributor-covenant.org/faq](https://www.contributor-covenant.org/faq)

README.md

@@ -12,18 +12,18 @@ This action provides the following functionality for GitHub Actions users:
 - Registering problem matchers for error output
 - Configuring authentication for GPR or npm
 
-## Breaking changes in V6
+## Breaking changes in v6
 
 - Caching is now automatically enabled for npm projects when either the `devEngines.packageManager` field or the top-level `packageManager` field in `package.json` is set to `npm`. For other package managers, such as Yarn and pnpm, caching is disabled by default and must be configured manually using the `cache` input.
 
 - The `always-auth` input has been removed, as it is deprecated and will no longer be supported in future npm releases. To ensure your workflows continue to run without warnings or errors, please remove any references to `always-auth` from your configuration.
 
-## Breaking changes in V5
+## Breaking changes in v5
 
 - Enabled caching by default with package manager detection if no cache input is provided.
   > For workflows with elevated privileges or access to sensitive information, we recommend disabling automatic caching by setting `package-manager-cache: false` when caching is not needed for secure operation.
 
-- Upgraded action from node20 to node24.
+- Upgraded action from Node.js 20 to Node.js 24.
   > Make sure your runner is on version v2.327.1 or later to ensure compatibility with this release. [See Release Notes](https://github.com/actions/runner/releases/tag/v2.327.1)
 
 For more details, see the full release notes on the [releases page](https://github.com/actions/setup-node/releases/v5.0.0)
@@ -47,12 +47,12 @@ See [action.yml](action.yml)
 
     # Set this option if you want the action to check for the latest available version
     # that satisfies the version spec.
-    # It will only get affect for lts Nodejs versions (12.x, >=10.15.0, lts/Hydrogen).
+    # It will only take effect for LTS Node.js versions (12.x, >=10.15.0, lts/Hydrogen).
     # Default: false
     check-latest: false
 
     # Target architecture for Node to use. Examples: x86, x64. Will use system architecture by default.
-    # Default: ''. The action use system architecture by default
+    # Default: ''. The action uses system architecture by default
     architecture: ''
 
     # Used to pull node distributions from https://github.com/actions/node-versions.
@@ -97,9 +97,9 @@ See [action.yml](action.yml)
     # Optional mirror to download binaries from.
     # Artifacts need to match the official Node.js
     # Example:
-    # V8 Canary Build: <mirror_url>/download/v8-canary
-    # RC Build: <mirror_url>/download/rc
-    # Official: Build <mirror_url>/dist
+    # V8 Canary build: <mirror_url>/download/v8-canary
+    # RC build: <mirror_url>/download/rc
+    # Official build: <mirror_url>/dist
     # Nightly build: <mirror_url>/download/nightly
     # Default: ''
     mirror: ''
@@ -123,7 +123,7 @@ steps:
 - run: npm test
 ```
 
-The `node-version` input is optional. If not supplied, the node version from PATH will be used. However, it is recommended to always specify Node.js version and not rely on the system one.
+The `node-version` input is optional. If not supplied, the Node.js version from PATH will be used. However, it is recommended to always specify the Node.js version and not rely on the system one.
 
 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/).
 
@@ -144,7 +144,7 @@ Examples:
 
 `current`/`latest`/`node` always resolve to the latest [dist version](https://nodejs.org/dist/index.json).
 That version is then downloaded from actions/node-versions if possible, or directly from Node.js if not.
-Since it will not be cached always, there is possibility of hitting rate limit when downloading from dist
+Since it will not always be cached, there is a possibility of hitting a rate limit when downloading from dist
 
 ### Checking in lockfiles
 
@@ -213,7 +213,7 @@ jobs:
     name: Node ${{ matrix.node }} sample
     steps:
       - uses: actions/checkout@v6
-      - name: Setup node
+      - name: Setup Node.js
         uses: actions/setup-node@v6
         with:
           node-version: ${{ matrix.node }}
@@ -223,7 +223,7 @@ jobs:
 
 ## Using `setup-node` on GHES
 
-`setup-node` comes pre-installed on the appliance with GHES if Actions is enabled. When dynamically downloading Nodejs distributions, `setup-node` downloads distributions from [`actions/node-versions`](https://github.com/actions/node-versions) on github.com (outside of the appliance). These calls to `actions/node-versions` are made via unauthenticated requests, which are limited to [60 requests per hour per IP](https://docs.github.com/en/rest/overview/resources-in-the-rest-api#rate-limiting). If more requests are made within the time frame, then you will start to see rate-limit errors during downloading that looks like: `##[error]API rate limit exceeded for...`. After that error the action will try to download versions directly from the official site, but it also can have rate limit so it's better to put token.
+`setup-node` comes pre-installed on the appliance with GHES if Actions is enabled. When dynamically downloading Node.js distributions, `setup-node` downloads distributions from [`actions/node-versions`](https://github.com/actions/node-versions) on github.com (outside of the appliance). These calls to `actions/node-versions` are made via unauthenticated requests, which are limited to [60 requests per hour per IP](https://docs.github.com/en/rest/overview/resources-in-the-rest-api#rate-limiting). If more requests are made within the time frame, then you will start to see rate-limit errors during downloading that looks like: `##[error]API rate limit exceeded for...`. After that error the action will try to download versions directly from the official site, but it also can have rate limit so it's better to put token.
 
 To get a higher rate limit, you can [generate a personal access token on github.com](https://github.com/settings/tokens/new) and pass it as the `token` input for the action:
 
@@ -234,7 +234,7 @@ with:
   node-version: 24
 ```
 
-If the runner is not able to access github.com, any Nodejs versions requested during a workflow run must come from the runner's tool cache. See "[Setting up the tool cache on self-hosted runners without internet access](https://docs.github.com/en/enterprise-server@3.2/admin/github-actions/managing-access-to-actions-from-githubcom/setting-up-the-tool-cache-on-self-hosted-runners-without-internet-access)" for more information.
+If the runner is not able to access github.com, any Node.js versions requested during a workflow run must come from the runner's tool cache. See "[Setting up the tool cache on self-hosted runners without internet access](https://docs.github.com/en/enterprise-server@3.2/admin/github-actions/managing-access-to-actions-from-githubcom/setting-up-the-tool-cache-on-self-hosted-runners-without-internet-access)" for more information.
 
 ## Advanced usage
 

__tests__/README.md

@@ -1,8 +1,8 @@
-Files located in data directory are used only for testing purposes. 
+Files located in the data directory are used only for testing purposes.
 
 
-## Here the list of files in the data directory
- - `.nvmrc`, `.tools-versions` and `package.json` are used to test node-version-file logic
+## Here is the list of files in the data directory
+ - `.nvmrc`, `.tool-versions` and `package.json` are used to test node-version-file logic
  - `package-lock.json`, `pnpm-lock.yaml` and `yarn.lock` are used to test cache logic 
  - `versions-manifest.json` is used for unit testing to check downloading Node.js versions from the node-versions repository.
  - `node-dist-index.json` is used for unit testing to check downloading Node.js versions from the official site. The file was constructed from https://nodejs.org/dist/index.json

docs/adrs/0000-caching-dependencies.md

@@ -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).

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

@@ -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

docs/advanced-usage.md

@@ -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.