Update release workflow and drop Node v20 support

[risantos]

Description

A recent security enhancement broke the current release workflow due to changes in the permissions.
We've had 2 release attempts failed, although still publishing to npmjs.

This update modifies the release workflow to support GitHub + NPM releases triggered by manually pushed tags.

• Updates release.yaml to trigger a release based on manually pushed tags.
• Updates release-it@21.0.2.
• Drop Node.js v20 support, and add v24 and v26 to CI.

After merge

We have to manually create tags for releases v10.1.0 and v11.0.0, which were pushed to npmjs, but haven't had tagged commits with the releases nor GitHub Releases.

v10.1.0 https://www.npmjs.com/package/validator.js-asserts/v/10.1.0

git tag v10.1.0 9d8b245
git push origin v10.1.0

v11.0.0 https://www.npmjs.com/package/validator.js-asserts/v/11.0.0

git tag v11.0.0 10ac352
git push origin v11.0.0

Then we'll open a PR to take care of the new release, v11.1.0, with updated changelogs and the actual v11.1.0 release commit.

[Copilot]

Pull request overview

This PR updates the project’s release tooling to accommodate recent GitHub Actions permission changes by shifting releases to be driven by pushed tags (and optionally manual dispatch), while upgrading release-it to a newer major version.

Changes:

• Update .github/workflows/release.yaml to run on v* tag pushes, resolve the tag for dispatch vs push events, and avoid duplicate releases.
• Upgrade release-it to ^21.0.2 (and refresh yarn.lock accordingly).
• Adjust .release-it.js and README guidance so release-it prepares the release commit, while the workflow handles tag-triggered GitHub/NPM releasing.

Reviewed changes

Copilot reviewed 4 out of 5 changed files in this pull request and generated 3 comments.

Show a summary per file

File	Description
.github/workflows/release.yaml	Switch release triggering to tag pushes + dispatch, add a pre-check job, and update action pins/permissions.
.release-it.js	Disable tagging/GitHub release/npm publish by default (intended for “release commit only” usage).
package.json	Bump release-it dependency to ^21.0.2.
yarn.lock	Lockfile updates resulting from the release-it upgrade.
README.md	Update documented release process to match the new tag-driven workflow.

---

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

[Copilot]

Pull request overview

Copilot reviewed 5 out of 6 changed files in this pull request and generated 1 comment.

Suppressed comments (3)

.github/workflows/release.yaml:30

• The workflow input/ref name is interpolated directly into a shell command. A manually supplied value (or valid Git tag name) containing shell substitution such as $(...) will execute with this job's contents: write and id-token: write permissions. Pass the expression through env and validate the expected release-tag format before writing it to GITHUB_OUTPUT; that also makes the later shell interpolation of this output safe.

    - name: Resolve version tag
      id: resolve-version-tag
      run: echo "tag=${{ github.event.inputs.tag || github.ref_name }}" >> "$GITHUB_OUTPUT"

.github/workflows/release.yaml:65

• Both backfill commits named in the PR currently declare package version 10.0.0, not 10.1.0 or 11.0.0. Consequently this check looks up validator.js-asserts@10.0.0, while the GitHub-release check uses the requested tag, and release-it --no-increment later derives v10.0.0 from the package version. Dispatching the documented tags therefore cannot create the intended v10.1.0/v11.0.0 GitHub releases. Derive and verify one version consistently from the tag, or backfill commits whose package versions match those tags.

        NAME=$(node -p "require('./package.json').name")
        VERSION=$(node -p "require('./package.json').version")

README.md:392

• The local release path is incomplete now that .release-it.js has a before:init hook that exits unless GITHUB_TOKEN is set. An admin following this instruction will fail immediately without knowing the required environment variable; document the token requirement and the actual command used to generate the release commit.

1. A release commit is pushed, via Pull Request (or an admin running `release-it` locally).