semantic-release 25.0.1-beta.3 → 25.0.2

package/docs/extending/plugins-list.md

@@ -213,3 +213,15 @@
 - [sr-uv-plugin](https://github.com/Artessan-Devs/sr-uv-plugin)
   - `verifyConditions`: Ensures `pyproject.toml` exists and contains a `[project]` section.
   - `prepare`: Updates the `[project].version` field in `pyproject.toml` to match the release version.
+- [semantic-release-uv](https://github.com/Deltamir/semantic-release-uv)
+  - `verifyConditions`: Verify the presence and validity of a `PYPI_TOKEN` and validate the `pyproject.toml` structure
+  - `prepare`: Update the version in `pyproject.toml`, locking and build the distribution with `uv`
+  - `publish`: Publish the package to PyPI or a custom index using `uv publish`
+- [@jno21/semantic-release-github-commit](https://github.com/Jno21/semantic-release-github-commit)
+  - **Notes**: This plugin creates a commit on GitHub using the GitHub API, enabling signed commits via a GitHub App.
+  - `verifyConditions`: Verify GitHub authentication and configuration.
+  - `prepare`: Create a commit with the specified files using the GitHub API.
+- [semantic-release-minecraft](https://github.com/pynickle/semantic-release)
+  - `verifyConditions`: Verify that all needed configuration is present.
+  - `prepare`: Convert different types of CurseForge game versions to their corresponding IDs.
+  - `publish`: Publish the Minecraft project to CurseForge and Modrinth.

package/docs/recipes/ci-configurations/github-actions.md

@@ -13,6 +13,10 @@ GitHub Actions is a [trusted identity provider](https://docs.npmjs.com/trusted-p
 The npm registry [recently increased restrictions for use of long-lived access tokens](https://github.blog/changelog/2025-09-29-strengthening-npm-security-important-changes-to-authentication-and-token-management/), further encouraging trusted publishing as the preferred approach for publishing to npm from GitHub Actions.
 Enabling trusted publishing requires granting the `id-token: write` permission to the job performing the publish step and [configuring a trust relationship](https://docs.npmjs.com/trusted-publishers#step-1-add-a-trusted-publisher-on-npmjscom) between your GitHub repository and npm.
 
+**Note**: When setting up a Trusted Publisher on npmjs for GitHub Actions, it's crucial to specify the workflow file that triggers the release process, not necessarily the one that contains the release logic itself.  
+If your release job is encapsulated in a [reusable workflow](https://docs.github.com/en/actions/how-tos/reuse-automations/reuse-workflows), the workflow file you must reference is the caller workflow—typically the one triggered by events like `push` or `workflow_dispatch` on your main branch.  
+This is because npm's Trusted Publisher mechanism authorizes the workflow that initiates the run, not any downstream workflows it invokes.
+
 [npm provenance](https://docs.npmjs.com/generating-provenance-statements) is valuable for increasing supply-chain security for your npm packages.
 Before trusted publishing was available, generating provenance attestations required configuring your project to enable publishing with provenance.
 With trusted publishing, npm provenance is automatically generated for packages published to npm from GitHub Actions without any additional configuration.

package/docs/support/node-version.md

@@ -1,6 +1,6 @@
 # Node version requirement
 
-**semantic-release** is written using the latest [ECMAScript 2017](https://www.ecma-international.org/publications/standards/Ecma-262.htm) features, without transpilation which **requires Node version 20.8.1 or higher**.
+**semantic-release** is written using the latest [ECMAScript 2017](https://www.ecma-international.org/publications/standards/Ecma-262.htm) features, without transpilation which **requires Node version 22.14.0 or higher**.
 
 **semantic-release** is meant to be used in a CI environment as a development support tool, not as a production dependency.
 Therefore, the only constraint is to run the `semantic-release` in a CI environment providing version of Node that meets our version requirement.
@@ -24,7 +24,7 @@ See [CI configuration](../usage/ci-configuration.md) and [CI configuration recip
 Use it to execute the `semantic-release` command.
 
 ```bash
-$ npx -p node@v18-lts -c "npx semantic-release"
+$ npx -p node@v24 -c "npx semantic-release"
 ```
 
 **Note**: See [What is npx](./FAQ.md#what-is-npx) for more details.

package/docs/usage/installation.md

@@ -1,44 +1,35 @@
 # Installation
 
-## Local installation
-
-For [Node modules projects](https://docs.npmjs.com/getting-started/creating-node-modules) we recommend installing **semantic-release** locally and running the `semantic-release` command with [npx](https://www.npmjs.com/package/npx):
-
-```bash
-npm install --save-dev semantic-release
-```
+## Global installation
 
-Then in the CI environment:
+We recommend installing **semantic-release** directly in the CI environment as part of executing with [npx](../support/FAQ.md#what-is-npx):
 
-```bash
+```sh
 npx semantic-release
 ```
 
-**Note:** `npx` is a tool bundled with `npm@>=5.2.0`. It is used to conveniently find the semantic-release binary and to execute it. See [What is npx](../support/FAQ.md#what-is-npx) for more details.
-
-## Global installation
+If you need to leverage plugins and/or presets that are not included in the base **semantic-release** package, you can install them part of executing with `npx` as well:
 
-For other type of projects we recommend installing **semantic-release** directly in the CI environment, also with [npx](https://www.npmjs.com/package/npx):
-
-```bash
-npx semantic-release
+```sh
+npx --package semantic-release --package @semantic-release/exec --package conventional-changelog-conventionalcommits semantic-release
 ```
 
 ### Notes
 
-1. If you've globally installed **semantic-release** then we recommend that you set the major **semantic-release** version to install.
-   For example, by using `npx semantic-release@18`.
-   This way you control which major version of **semantic-release** is used by your build, and thus avoid breaking the build when there's a new major version of **semantic-release**.
+1. When globally installing **semantic-release** as part of running with `npx`, we recommend setting at least the major **semantic-release** version to install.
+   For example, by using `npx semantic-release@25`.
+   This way you control which major version of **semantic-release** is used by your pipeline, and thus avoid breaking the release when there's a new major version of **semantic-release**.
 2. Pinning **semantic-release** to an exact version makes your releases even more deterministic.
    But pinning also means you, or a bot, must upgrade **semantic-release** when a new version is released.
 3. You can use [Renovate's regex manager](https://docs.renovatebot.com/modules/manager/regex/) to get automatic updates for **semantic-release** in either of the above scenarios.
    Put this in your Renovate configuration file:
    ```json
    {
-     "regexManagers": [
+     "customManagers": [
        {
+         "customType": "regex",
          "description": "Update semantic-release version used by npx",
-         "fileMatch": ["^\\.github/workflows/[^/]+\\.ya?ml$"],
+         "managerFilePatterns": ["^\\.github/workflows/[^/]+\\.ya?ml$"],
          "matchStrings": ["\\srun: npx semantic-release@(?<currentValue>.*?)\\s"],
          "datasourceTemplate": "npm",
          "depNameTemplate": "semantic-release"
@@ -48,3 +39,13 @@ npx semantic-release
    ```
 4. `npx` is a tool bundled with `npm@>=5.2.0`. You can use it to install (and run) the **semantic-release** binary.
    See [What is npx](../support/FAQ.md#what-is-npx) for more details.
+
+## Local installation
+
+Since **semantic-release** isn't truly a development dependency, but rather a release dependency, we recommend avoiding installation as a local dependency of your project.
+Instead, we recommend installing it globally in your CI environment as part of executing with [npx](../support/FAQ.md#what-is-npx) as described [above](#global-insallation).
+Installing only during the release process avoids:
+
+- installing unnecessary dependencies during development and testing, including the fairly sizable dependency on **npm**
+- installing a different version of **npm** into `node_modules/` than the one used to run the release, which can lead to conflicts and unexpected behavior
+- installing dependencies that could conflict with other development dependencies, like **commitlint**

package/package.json

@@ -1,7 +1,7 @@
 {
   "name": "semantic-release",
   "description": "Automated semver compliant package publishing",
-  "version": "25.0.1-beta.3",
+  "version": "25.0.2",
   "type": "module",
   "author": "Stephan Bönnemann <stephan@boennemann.me> (http://boennemann.me)",
   "ava": {
@@ -50,7 +50,7 @@
     "micromatch": "^4.0.2",
     "p-each-series": "^3.0.0",
     "p-reduce": "^3.0.0",
-    "read-package-up": "^11.0.0",
+    "read-package-up": "^12.0.0",
     "resolve-from": "^5.0.0",
     "semver": "^7.3.2",
     "semver-diff": "^5.0.0",
@@ -58,7 +58,7 @@
     "yargs": "^18.0.0"
   },
   "devDependencies": {
-    "@types/node": "22.18.10",
+    "@types/node": "24.10.0",
     "@types/signale": "1.4.7",
     "ava": "6.4.1",
     "c8": "10.1.3",
@@ -67,7 +67,7 @@
     "dockerode": "4.0.9",
     "file-url": "4.0.0",
     "fs-extra": "11.3.2",
-    "got": "14.5.0",
+    "got": "14.6.2",
     "js-yaml": "4.1.0",
     "lockfile-lint": "4.14.1",
     "ls-engines": "0.9.3",
@@ -76,7 +76,7 @@
     "npm-run-all2": "8.0.4",
     "p-retry": "7.1.0",
     "prettier": "3.6.2",
-    "publint": "0.3.14",
+    "publint": "0.3.15",
     "sinon": "21.0.0",
     "stream-buffers": "3.0.3",
     "tempy": "3.1.0",