semantic-release
Advanced tools
semantic-release - npm Package Compare versions
@@ -216,1 +216,13 @@ # Plugins list | ||
| - `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. |
@@ -16,2 +16,6 @@ # Using semantic-release with [GitHub Actions](https://help.github.com/en/categories/automating-your-workflow-with-github-actions) | ||
| **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. | ||
@@ -18,0 +22,0 @@ Before trusted publishing was available, generating provenance attestations required configuring your project to enable publishing with provenance. |
| # 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**. | ||
@@ -27,3 +27,3 @@ **semantic-release** is meant to be used in a CI environment as a development support tool, not as a production dependency. | ||
| ```bash | ||
| $ npx -p node@v18-lts -c "npx semantic-release" | ||
| $ npx -p node@v24 -c "npx semantic-release" | ||
| ``` | ||
@@ -30,0 +30,0 @@ |
| # Installation | ||
| ## Local installation | ||
| ## Global 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): | ||
| We recommend installing **semantic-release** directly in the CI environment as part of executing with [npx](../support/FAQ.md#what-is-npx): | ||
| ```bash | ||
| npm install --save-dev semantic-release | ||
| ``` | ||
| Then in the CI environment: | ||
| ```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. | ||
| 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: | ||
| ## Global installation | ||
| 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 | ||
| ``` | ||
@@ -29,5 +19,5 @@ | ||
| 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. | ||
@@ -39,6 +29,7 @@ But pinning also means you, or a bot, must upgrade **semantic-release** when a new version is released. | ||
| { | ||
| "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"], | ||
@@ -53,1 +44,11 @@ "datasourceTemplate": "npm", | ||
| 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** |
+5
-5
| { | ||
| "name": "semantic-release", | ||
| "description": "Automated semver compliant package publishing", | ||
| "version": "25.0.1", | ||
| "version": "25.0.2", | ||
| "type": "module", | ||
@@ -53,3 +53,3 @@ "author": "Stephan Bönnemann <stephan@boennemann.me> (http://boennemann.me)", | ||
| "p-reduce": "^3.0.0", | ||
| "read-package-up": "^11.0.0", | ||
| "read-package-up": "^12.0.0", | ||
| "resolve-from": "^5.0.0", | ||
@@ -62,3 +62,3 @@ "semver": "^7.3.2", | ||
| "devDependencies": { | ||
| "@types/node": "22.18.11", | ||
| "@types/node": "24.10.0", | ||
| "@types/signale": "1.4.7", | ||
@@ -72,3 +72,3 @@ "ava": "6.4.1", | ||
| "fs-extra": "11.3.2", | ||
| "got": "14.6.0", | ||
| "got": "14.6.2", | ||
| "js-yaml": "4.1.0", | ||
@@ -82,3 +82,3 @@ "lockfile-lint": "4.14.1", | ||
| "prettier": "3.6.2", | ||
| "publint": "0.3.14", | ||
| "publint": "0.3.15", | ||
| "sinon": "21.0.0", | ||
@@ -85,0 +85,0 @@ "stream-buffers": "3.0.3", |
New alerts
Environment variable access
Supply chain riskPackage accesses environment variables, which may be a sign of credential stuffing or data theft.
Found 1 instance in 1 package
Long strings
Supply chain riskContains long string literals, which may be a sign of obfuscated or packed code.
Found 1 instance in 1 package
URL strings
Supply chain riskPackage contains fragments of external URLs or IP addresses, which the package may be accessing at runtime.
Found 1 instance in 1 package
Fixed alerts
Environment variable access
Supply chain riskPackage accesses environment variables, which may be a sign of credential stuffing or data theft.
Found 1 instance in 1 package
Long strings
Supply chain riskContains long string literals, which may be a sign of obfuscated or packed code.
Found 1 instance in 1 package
URL strings
Supply chain riskPackage contains fragments of external URLs or IP addresses, which the package may be accessing at runtime.
Found 1 instance in 1 package
Improved metrics
- Total package byte prevSize
296948
0.78%Dependency changes
+ Added
read-package-up@12.0.0(transitive)Updated
read-package-up@^12.0.0