mirror of
https://github.com/sablierapp/sablier.git
synced 2026-01-01 02:27:23 +01:00
docs(release): update doc version from 1.3.0-beta.1 to 1.3.0-beta.2 [skip ci]
This commit is contained in:
semantic-release-bot
222
node_modules/semantic-release/docs/support/FAQ.md
generated
vendored
Normal file
222
node_modules/semantic-release/docs/support/FAQ.md
generated
vendored
Normal file
@@ -0,0 +1,222 @@
|
||||
# Frequently Asked Questions
|
||||
|
||||
## Why is the `package.json`’s version not updated in my repository?
|
||||
|
||||
[`@semantic-release/npm`](https://github.com/semantic-release/npm) takes care of updating the `package.json`’s version before publishing to [npm](https://www.npmjs.com).
|
||||
|
||||
By default, only the published package will contain the version, which is the only place where it is _really_ required, but the updated `package.json` will not be pushed to the Git repository
|
||||
|
||||
However, the [`@semantic-release/git`](https://github.com/semantic-release/git) plugin can be used to push the updated `package.json` as well as other files to the Git repository.
|
||||
|
||||
If you wish to only update the `package.json` and push via Git you can set the project to `"private": true,` within your `package.json` to prevent publishing to [the npm registry](https://www.npmjs.com).
|
||||
|
||||
## How can I use a npm build script that requires the `package.json`’s version ?
|
||||
|
||||
The `package.json`’s version will be updated by the `semantic-release` command just before publishing to [npm](https://www.npmjs.com), therefore it won't be available for scripts ran before the `semantic-release` command.
|
||||
|
||||
As the [`@semantic-release/npm`](https://github.com/semantic-release/npm) plugin uses the [npm CLI](https://docs.npmjs.com/cli/npm) to update the `package.json` version and publish the package, all [npm hook scripts](https://docs.npmjs.com/misc/scripts#description) will be executed.
|
||||
|
||||
You can run your build script in:
|
||||
|
||||
- the `prepublishOnly` or `prepack` hook so it will be executed during the `publish` step of `@semantic-release/npm`
|
||||
- the `postversion` hook so it will be executed during the `prepare` step of `@semantic-release/npm`, which allow for example to update files before committing them with the [`@semantic-release/git`](https://github.com/semantic-release/git) plugin
|
||||
|
||||
If using npm hook scripts is not possible, and alternative solution is to [`@semantic-release/exec`](https://github.com/semantic-release/exec) plugin to run your script in the `prepare` step:
|
||||
|
||||
```json
|
||||
{
|
||||
"plugins": [
|
||||
"@semantic-release/commit-analyzer",
|
||||
"@semantic-release/release-notes-generator",
|
||||
"@semantic-release/npm",
|
||||
[
|
||||
"@semantic-release/exec",
|
||||
{
|
||||
"prepareCmd": "./my-build-script.sh ${nextRelease.version}"
|
||||
}
|
||||
]
|
||||
]
|
||||
}
|
||||
```
|
||||
|
||||
## Is there a way to preview which version would currently get published?
|
||||
|
||||
Yes with the [dry-run options](../usage/configuration.md#dryrun) which prints to the console the next version to be published and the release notes.
|
||||
|
||||
## Can I use semantic-release to publish non-JavaScript packages?
|
||||
|
||||
Yes, **semantic-release** is a Node CLI application, but it can be used to publish any type of packages.
|
||||
|
||||
To publish a non-Node package (without a `package.json`) you would need to:
|
||||
|
||||
- Use a [global](../usage/installation.md#global-installation) **semantic-release** installation
|
||||
- Set **semantic-release** [options](../usage/configuration.md#options) via [CLI arguments or `.rc` file](../usage/configuration.md#configuration)
|
||||
- Make sure your CI job executing the `semantic-release` command has access to a version of Node that [meets our version requirement](./node-version.md) to execute the `semantic-release` command
|
||||
|
||||
See the [CI configuration recipes](../recipes/release-workflow/README.md#ci-configurations) for more details on specific CI environments.
|
||||
|
||||
In addition, you will need to configure the **semantic-release** [plugins](../usage/plugins.md#plugins) to disable the [`@semantic-release/npm`](https://github.com/semantic-release/npm) plugin which is used by default and use a plugin for your project type.
|
||||
|
||||
If there is no specific plugin for your project type you can use the [`@semantic-release/exec`](https://github.com/semantic-release/exec) plugin to publish the release with a shell command.
|
||||
|
||||
Here is a basic example to create [GitHub releases](https://help.github.com/articles/about-releases) and use a shell command to publish:
|
||||
|
||||
```json
|
||||
{
|
||||
"plugins": [
|
||||
"@semantic-release/commit-analyzer",
|
||||
"@semantic-release/release-notes-generator",
|
||||
"@semantic-release/github",
|
||||
[
|
||||
"@semantic-release/exec",
|
||||
{
|
||||
"prepareCmd": "set-version ${nextRelease.version}",
|
||||
"publishCmd": "publish-package"
|
||||
}
|
||||
]
|
||||
]
|
||||
}
|
||||
```
|
||||
|
||||
**Note**: This is a theoretical example where the command `set-version` update the project version with the value passed as its first argument and `publish-package` publishes the package to a registry.
|
||||
|
||||
See the [package managers and languages recipes](../recipes/release-workflow/README.md#package-managers-and-languages) for more details on specific project types.
|
||||
|
||||
## Can I use semantic-release with any CI service?
|
||||
|
||||
Yes, **semantic-release** can be used with any CI service, as long as it provides:
|
||||
|
||||
- A way to set [authentication](../usage/ci-configuration.md#authentication) via environment variables
|
||||
- A way to guarantee that the `semantic-release` command is [executed only after all the tests of all the jobs in the CI build pass](../usage/ci-configuration.md#run-semantic-release-only-after-all-tests-succeeded)
|
||||
|
||||
See the [CI configuration recipes](../recipes/release-workflow/README.md#ci-configurations) for more details on specific CI environments.
|
||||
|
||||
## Can I run semantic-release on my local machine rather than on a CI server?
|
||||
|
||||
Yes, you can by explicitly setting the [`--no-ci` CLI option](../usage/configuration.md#ci) option. You will also have to set the required [authentication](../usage/ci-configuration.md#authentication) via environment variables on your local machine, for example:
|
||||
|
||||
```bash
|
||||
$ NPM_TOKEN=<your_npm_token> GH_TOKEN=<your_github_token> npx semantic-release --no-ci
|
||||
```
|
||||
|
||||
However this is not the recommended approach, as running unit and integration tests on an independent machine before publishing software is a crucial part of the release workflow.
|
||||
|
||||
## Can I use semantic-release with GitLab?
|
||||
|
||||
Yes, with the [`@semantic-release/gitlab-config`](https://github.com/semantic-release/gitlab-config) shareable configuration.
|
||||
|
||||
See the [GitLab CI recipes](../recipes/ci-configurations/gitlab-ci.md#using-semantic-release-with-gitlab-ci) for the CI configuration.
|
||||
|
||||
## Can I use semantic-release with any Git hosted environment?
|
||||
|
||||
By default **semantic-release** uses the [`@semantic-release/github`](https://github.com/semantic-release/github) plugin to publish a [GitHub release](https://help.github.com/articles/about-releases). For other Git hosted environment the [`@semantic-release/git`](https://github.com/semantic-release/git) and [`@semantic-release/changelog`](https://github.com/semantic-release/changelog) plugins can be used via [plugins configuration](../usage/plugins.md).
|
||||
|
||||
See the [`@semantic-release/git`](https://github.com/semantic-release/git#semantic-releasegit) [`@semantic-release/changelog`](https://github.com/semantic-release/changelog#semantic-releasechangelog) plugins documentation for more details.
|
||||
|
||||
## Can I skip the release to the npm registry?
|
||||
|
||||
Yes, the publishing to the npm registry can be disabled with the [`npmPublish`](https://github.com/semantic-release/npm#options) option of the [`@semantic-release/npm`](https://github.com/semantic-release/npm) plugin. In addition the [`tarballDir`](https://github.com/semantic-release/npm#options) option allow to generate the package tarball in order to publish it to your repository with the [`@semantic-release/git`](https://github.com/semantic-release/git) or to a [GitHub release](https://help.github.com/articles/about-releases) with the [`@semantic-release/github`](https://github.com/semantic-release/github) plugin.
|
||||
|
||||
See the [`@semantic-release/npm`](https://github.com/semantic-release/npm#semantic-releasenpm) plugin documentation for more details.
|
||||
|
||||
## How can I revert a release?
|
||||
|
||||
If you have introduced a breaking bug in a release you have 2 options:
|
||||
|
||||
- If you have a fix immediately ready, commit and push it (or merge it via a pull request) to the release branch
|
||||
- Otherwise, [revert the commit](https://git-scm.com/docs/git-revert) that introduced the bug and push the revert commit (or merge it via a pull request) to the release branch
|
||||
|
||||
In both cases **semantic-release** will publish a new release, so your package users will get the fixed/reverted version.
|
||||
|
||||
Depending on the package manager you are using, you might be able to un-publish or deprecate a release, in order to prevent users from downloading it by accident. For example, npm allows you to [un-publish](https://docs.npmjs.com/cli/unpublish) [within 72 hours](https://www.npmjs.com/policies/unpublish) after release. You may also [deprecate](https://docs.npmjs.com/cli/deprecate) a release if you would rather avoid un-publishing.
|
||||
|
||||
In any case **do not remove the Git tag associated with the buggy version**, otherwise **semantic-release** will later try to republish that version. Publishing a version after un-publishing is not supported by most package managers.
|
||||
|
||||
**Note**: If you are using the default [Angular Commit Message Conventions](https://github.com/angular/angular.js/blob/master/DEVELOPERS.md#-git-commit-guidelines) be aware that it uses a different revert commit format than the standard one created by [git revert](https://git-scm.com/docs/git-revert), contrary to what is [claimed in the convention](https://github.com/angular/angular.js/blob/master/DEVELOPERS.md#revert). Therefore, if you revert a commit with [`git revert`](https://git-scm.com/docs/git-revert), use the [`--edit` option](https://git-scm.com/docs/git-revert#git-revert---edit) to format the message according to the [Angular revert commit message format](https://github.com/angular/angular.js/blob/master/DEVELOPERS.md#revert). See [conventional-changelog/conventional-changelog#348](https://github.com/conventional-changelog/conventional-changelog/issues/348) for more details.
|
||||
|
||||
## Can I use `.npmrc` options?
|
||||
|
||||
Yes, all the [npm configuration options](https://docs.npmjs.com/misc/config) are supported via the [`.npmrc`](https://docs.npmjs.com/files/npmrc) file at the root of your repository.
|
||||
|
||||
See the [`@semantic-release/npm`](https://github.com/semantic-release/npm#npm-configuration) plugin documentation for more details.
|
||||
|
||||
## How can I set the access level of the published npm package?
|
||||
|
||||
The [npm `access` option](https://docs.npmjs.com/misc/config#access) can be set in the [`.npmrc`](https://docs.npmjs.com/files/npmrc) file at the root of your repository:
|
||||
|
||||
```rc
|
||||
access=public
|
||||
```
|
||||
|
||||
Or with the `publishConfig.access` key in your project's `package.json`:
|
||||
|
||||
```json
|
||||
{
|
||||
"publishConfig": {
|
||||
"access": "public"
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
## Can I use semantic-release to publish a package on Artifactory?
|
||||
|
||||
Any npm compatible registry is supported with the [`@semantic-release/npm`](https://github.com/semantic-release/npm) plugin. For Artifactory versions prior to 5.4, the legacy authentication has to be used (with `NPM_USERNAME`, `NPM_PASSWORD` and `NPM_EMAIL` [environment variables](https://github.com/semantic-release/npm#environment-variables)).
|
||||
|
||||
See [npm registry authentication](https://github.com/semantic-release/npm#npm-registry-authentication) for more details.
|
||||
|
||||
See [Artifactory - npm Registry](https://www.jfrog.com/confluence/display/RTF/Npm+Registry#NpmRegistry-AuthenticatingthenpmClient) documentation for Artifactory configuration.
|
||||
|
||||
## Can I manually trigger the release of a specific version?
|
||||
|
||||
You can trigger a release by pushing to your Git repository. You deliberately cannot trigger a _specific_ version release, because this is the whole point of semantic-release.
|
||||
|
||||
## Can I exclude commits from the analysis?
|
||||
|
||||
Yes, every commits that contains `[skip release]` or `[release skip]` in their message will be excluded from the commit analysis and won't participate in the release type determination.
|
||||
|
||||
## How can I change the type of commits that trigger a release?
|
||||
|
||||
By default **semantic-release** uses the [Angular Commit Message Conventions](https://github.com/angular/angular.js/blob/master/DEVELOPERS.md#-git-commit-guidelines) and triggers releases based on the following rules:
|
||||
|
||||
| Commit | Release type |
|
||||
| --------------------------- | -------------------------- |
|
||||
| Commit with breaking change | ~~Major~~ Breaking release |
|
||||
| Commit with type `feat` | ~~Minor~~ Feature release |
|
||||
| Commit with type `fix` | Patch release |
|
||||
| Commit with type `perf` | Patch release |
|
||||
|
||||
See the [`@semantic-release/npm`](https://github.com/semantic-release/npm#npm-configuration) plugin documentation for more details.
|
||||
|
||||
This is fully customizable with the [`@semantic-release/commit-analyzer`](https://github.com/semantic-release/commit-analyzer) plugin's [`release-rules` option](https://github.com/semantic-release/commit-analyzer#release-rules).
|
||||
|
||||
## Is it _really_ a good idea to release on every push?
|
||||
|
||||
It is indeed a great idea because it _forces_ you to follow best practices. If you don’t feel comfortable releasing every feature or fix on your `master` you might not treat your `master` branch as intended.
|
||||
|
||||
From [Understanding the GitHub Flow](https://guides.github.com/introduction/flow/index.html):
|
||||
|
||||
> Branching is a core concept in Git, and the entire GitHub Flow is based upon it. There's only one rule: anything in the master branch is always deployable.
|
||||
|
||||
If you need more control over the timing of releases, see [Triggering a release](../../README.md#triggering-a-release) for different options.
|
||||
|
||||
**Note**: Only the codebase changes altering the published package will trigger a release (for example new features, bug fixes or performance improvements would trigger a release while refactoring or changing code style would not). See [How can I change the type of commits that trigger a release?](#how-can-i-change-the-type-of-commits-that-trigger-a-release) for more details.
|
||||
|
||||
## Can I set the initial release version of my package to `0.0.1`?
|
||||
|
||||
This is not supported by **semantic-release** as it's not considered a good practice, mostly because [Semantic Versioning](https://semver.org) rules applies differently to major version zero.
|
||||
|
||||
If your project is under heavy development, with frequent breaking changes, and is not production ready yet we recommend [publishing pre-releases](../recipes/release-workflow/pre-releases.md#publishing-pre-releases).
|
||||
|
||||
See [“Introduction to SemVer” - Irina Gebauer](https://blog.greenkeeper.io/introduction-to-semver-d272990c44f2) for more details on [Semantic Versioning](https://semver.org) and the recommendation to start at version `1.0.0`.
|
||||
|
||||
## Can I trust semantic-release with my releases?
|
||||
|
||||
**semantic-release** has a full unit and integration test suite that tests `npm` publishes against the [verdaccio](https://www.npmjs.com/package/verdaccio).
|
||||
|
||||
In addition, the [verify conditions step](../../README.md#release-steps) verifies that all necessary conditions for proceeding with a release are met, and a new release will be performed [only if all your tests pass](../usage/ci-configuration.md#run-semantic-release-only-after-all-tests-succeeded).
|
||||
|
||||
## What is npx?
|
||||
|
||||
[`npx`](https://www.npmjs.com/package/npx) – short for "npm exec" – is a CLI to find and execute npm binaries within the local `node_modules` folder or in the $PATH. If a binary can't be located npx will download the required package and execute it from its cache location.
|
||||
The tool is bundled with [npm](https://www.npmjs.com/package/npm) >= 5.2, or can be installed via `npm install -g npx`.
|
||||
For more details and motivation read the [introductory blog post](https://medium.com/@maybekatz/introducing-npx-an-npm-package-runner-55f7d4bd282b) by [@zkat](https://github.com/zkat).
|
||||
7
node_modules/semantic-release/docs/support/README.md
generated
vendored
Normal file
7
node_modules/semantic-release/docs/support/README.md
generated
vendored
Normal file
@@ -0,0 +1,7 @@
|
||||
# Support
|
||||
|
||||
- [Resources](resources.md) - Videos, articles and tutorials
|
||||
- [Frequently Asked Questions](FAQ.md)
|
||||
- [Troubleshooting](troubleshooting.md)
|
||||
- [Node version requirement](node-version.md)
|
||||
- [Node Support Policy](node-support-policy.md)
|
||||
4
node_modules/semantic-release/docs/support/git-version.md
generated
vendored
Normal file
4
node_modules/semantic-release/docs/support/git-version.md
generated
vendored
Normal file
@@ -0,0 +1,4 @@
|
||||
# Git version requirement
|
||||
|
||||
**semantic-release** uses Git CLI commands to read information about the repository such as branches, commit history and tags.
|
||||
Certain commands and options (such as [the `--merged` option of the `git tag` command](https://git-scm.com/docs/git-tag/2.7.0#git-tag---no-mergedltcommitgt) or bug fixes related to `git ls-files`) used by **semantic-release** are only available in Git version 2.7.1 and higher.
|
||||
21
node_modules/semantic-release/docs/support/node-support-policy.md
generated
vendored
Normal file
21
node_modules/semantic-release/docs/support/node-support-policy.md
generated
vendored
Normal file
@@ -0,0 +1,21 @@
|
||||
# Node Support Policy
|
||||
|
||||
We will always support at least the latest [Long-Term Support](https://github.com/nodejs/Release) version of Node, but provide no promise of support for older versions.
|
||||
The supported range will always be defined in the `engines.node` property of the `package.json` of our packages.
|
||||
|
||||
We specifically limit our support to LTS versions of Node, not because this package won't work on other versions, but because we have a limited amount of time, and supporting LTS offers the greatest return on that investment.
|
||||
|
||||
It's possible this package will work correctly on newer versions of Node.
|
||||
It may even be possible to use this package on older versions of Node, though that's more unlikely as we'll make every effort to take advantage of features available in the oldest LTS version we support.
|
||||
|
||||
As new Node LTS versions become available we may remove previous versions from the `engines.node` property of our package's `package.json` file.
|
||||
Removing a Node version is considered a breaking change and will entail the publishing of a new major version of this package.
|
||||
We will not accept any requests to support an end-of-life version of Node.
|
||||
Any merge requests or issues supporting an end-of-life version of Node will be closed.
|
||||
|
||||
We will accept code that allows this package to run on newer, non-LTS, versions of Node.
|
||||
Furthermore, we will attempt to ensure our own changes work on the latest version of Node.
|
||||
To help in that commitment, our continuous integration setup runs against all LTS versions of Node in addition the most recent Node release; called current.
|
||||
|
||||
JavaScript package managers should allow you to install this package with any version of Node, with, at most, a warning if your version of Node does not fall within the range specified by our node engines property.
|
||||
If you encounter issues installing this package, please report the issue to your package manager.
|
||||
38
node_modules/semantic-release/docs/support/node-version.md
generated
vendored
Normal file
38
node_modules/semantic-release/docs/support/node-version.md
generated
vendored
Normal file
@@ -0,0 +1,38 @@
|
||||
# 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 18.0.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.
|
||||
|
||||
See our [Node Support Policy](node-support-policy.md) for our long-term promise regarding Node version support.
|
||||
|
||||
## Recommended solution
|
||||
|
||||
### Run at least one CI job with a version of Node that meets our version requirement
|
||||
|
||||
The recommended approach is to run the `semantic-release` command from a CI job running on the latest available LTS version of node.
|
||||
This can either be a job used by your project to test on the latest Node LTS version or a dedicated job for the release steps.
|
||||
|
||||
See [CI configuration](../usage/ci-configuration.md) and [CI configuration recipes](../recipes/release-workflow/README.md#ci-configurations) for more details.
|
||||
|
||||
## Alternative solutions
|
||||
|
||||
### Use `npx` to execute in the latest LTS version of Node
|
||||
|
||||
`npx` is included with npm >= 5.2 and can be used to download the latest [Node LTS package published on npm](https://www.npmjs.com/package/node).
|
||||
Use it to execute the `semantic-release` command.
|
||||
|
||||
```bash
|
||||
$ npx -p node@v18-lts -c "npx semantic-release"
|
||||
```
|
||||
|
||||
**Note**: See [What is npx](./FAQ.md#what-is-npx) for more details.
|
||||
|
||||
### Use `nvm`
|
||||
|
||||
If your CI environment provides [nvm](https://github.com/creationix/nvm) you can use it to switch to the latest LTS version of Node before running the `semantic-release` command.
|
||||
|
||||
```bash
|
||||
$ nvm install 'lts/*' && npx semantic-release
|
||||
```
|
||||
22
node_modules/semantic-release/docs/support/resources.md
generated
vendored
Normal file
22
node_modules/semantic-release/docs/support/resources.md
generated
vendored
Normal file
@@ -0,0 +1,22 @@
|
||||
# Resources
|
||||
|
||||
## Videos
|
||||
|
||||
- ["Introducing Reliable Dependency and Release Management for npm Packages" - Gregor Martynus](https://www.youtube.com/watch?v=R2RJWLcfzwc)
|
||||
- ["Kill all humans" - Jan Lehnardt](https://www.youtube.com/watch?v=ZXyx_1kN1L8&t=2s)
|
||||
- ["Publishing JavaScript Packages" - JavaScript Air](https://javascriptair.com/episodes/2016-07-20)
|
||||
- ["Managing Dependencies like a boss 😎" - JavaScript Air](https://javascriptair.com/episodes/2016-08-17)
|
||||
- ["Dependency Hell Just Froze Over" - Stephan Bönnemann](https://www.youtube.com/watch?v=PA139CERNbc)
|
||||
- ["semantic-release Q&A with Kent C. Dodds"](https://www.youtube.com/watch?v=g6y3DnhkjrI)
|
||||
- ["We fail to follow SemVer – and why it needn’t matter" - Stephan Bönnemann](https://www.youtube.com/watch?v=tc2UgG5L7WM)
|
||||
|
||||
## Articles
|
||||
|
||||
- ["Introduction to SemVer" - Irina Gebauer](https://blog.greenkeeper.io/introduction-to-semver-d272990c44f2)
|
||||
- ["Introduction to Semantic Release" - liv](https://blog.greenkeeper.io/introduction-to-semantic-release-33f73b117c8)
|
||||
- ["Series - Semantic Release Automation" - Abdelrahman Wahdan](https://dev.to/abdelrahmanahmed/semantic-release-and-how-to-automate-it-part-1-4pa2)
|
||||
- ["Explain semantic release and how to use it on GitLab pipeline"](https://regoo707.medium.com/auto-bump-apps-versions-and-releases-using-gitlab-pipeline-e32f1d7fa3ee)
|
||||
|
||||
## Tutorials
|
||||
|
||||
- ["How to Write a JavaScript Library - Automating Releases with semantic-release" – egghead.io](https://egghead.io/lessons/javascript-automating-releases-with-semantic-release)
|
||||
70
node_modules/semantic-release/docs/support/troubleshooting.md
generated
vendored
Normal file
70
node_modules/semantic-release/docs/support/troubleshooting.md
generated
vendored
Normal file
@@ -0,0 +1,70 @@
|
||||
# Troubleshooting
|
||||
|
||||
## You do not have permission to publish 'package-name'
|
||||
|
||||
When running semantic-release you might encounter the following error:
|
||||
|
||||
```bash
|
||||
npm ERR! publish Failed PUT 403
|
||||
npm ERR! code E403
|
||||
npm ERR! You do not have permission to publish "<package-name>". Are you logged in as the correct user? : <package-name>
|
||||
```
|
||||
|
||||
This is most likely related to a misconfiguration of the [npm registry authentication](https://github.com/semantic-release/npm#npm-registry-authentication) or to your user [missing permission](https://docs.npmjs.com/cli/team) for publishing.
|
||||
|
||||
It might also happen if the package name you are trying to publish already exists (in the case of npm, you may be trying to publish a new version of a package that is not yours, hence the permission error).
|
||||
|
||||
To verify if your package name is available you can use [npm-name-cli](https://github.com/sindresorhus/npm-name-cli):
|
||||
|
||||
```bash
|
||||
$ npm install --global npm-name-cli
|
||||
$ npm-name <package-name>
|
||||
```
|
||||
|
||||
If the package name is not available, change it in your `package.json` or consider using an [npm scope](https://docs.npmjs.com/misc/scope).
|
||||
|
||||
## Squashed commits are ignored by **semantic-release**
|
||||
|
||||
**semantic-release** parses commits according to a [commit message convention](https://github.com/semantic-release/semantic-release#commit-message-format) to figure out how they affect the codebase. Commits that doesn't follow the project's commit message convention are simply ignored.
|
||||
|
||||
When [squashing commits](https://git-scm.com/book/en/v2/Git-Tools-Rewriting-History#_squashing) most Git tools will by default generate a new commit message with a summary of the squashed commits. This commit message will most likely not be compliant with the project's commit message convention and therefore will be ignored by **semantic-release**.
|
||||
|
||||
When squashing commits make sure to rewrite the resulting commit message to be compliant with the project's commit message convention.
|
||||
|
||||
**Note**: if the resulting squashed commit encompasses multiple changes (for example multiple unrelated features or fixes) then it's probably not a good idea to squash those commits together. A commit should contain exactly one self-contained functional change and a functional change should be contained in exactly one commit. See [atomic commits](https://en.wikipedia.org/wiki/Atomic_commit).
|
||||
|
||||
## `reference already exists` error when pushing tag
|
||||
|
||||
**semantic-release** read [Git tags](https://git-scm.com/book/en/v2/Git-Basics-Tagging) that are present in the history of your release branch in order to determine the last release published. Then it determines the next version to release based on the commits pushed since then and create the corresponding tag.
|
||||
If a tag with the name already in your repository, Git will throw and error as tags must be unique across the repository.
|
||||
This situation happens when you have a version tag identical to the new one **semantic-release** is trying to create that is not in the history of the current branch.
|
||||
|
||||
If an actual release with that version number was published you need to merge all the commits up to that release into your release branch.
|
||||
|
||||
If there is no published release with that version number, the tag must be deleted.
|
||||
|
||||
```bash
|
||||
# Verify if the commit exists in the repository
|
||||
$ git rev-list -1 <tag name>
|
||||
# If a commit sha is returned, then the tag exists
|
||||
|
||||
# Verify the branches having the tagged commit in their history
|
||||
$ git branch --contains <tag name>
|
||||
|
||||
# Delete the tag
|
||||
$ git tag -d <tag name>
|
||||
$ git push origin :refs/tags/<tag name>
|
||||
```
|
||||
|
||||
## release not found release branch after `git push --force`
|
||||
|
||||
**semantic-release** is using both [git tags](https://git-scm.com/docs/git-tag) and [git notes](https://git-scm.com/docs/git-notes) to store information about which releases happened in which branch.
|
||||
|
||||
After a git history rewrite due to a `git push --force`, the git tags and notes referencing the commits that were rewritten are lost.
|
||||
|
||||
To recover from that situation, do the following:
|
||||
|
||||
1. Delete the tag(s) for the release(s) that have been lost from the git history. You can delete each tag from remote using `git push origin -d :[TAG NAME]`, e.g. `git push origin -d :v2.0.0-beta.1`. You can delete tags locally using `git tag -d [TAG NAME]`, e.g. `git tag -d v2.0.0-beta.1`.
|
||||
2. Re-create the tags locally: `git tag [TAG NAME] [COMMIT HASH]`, where `[COMMIT HASH]` is the new commit that created the release for the lost tag. E.g. `git tag v2.0.0-beta.1 abcdef0`
|
||||
3. Re-create the git notes for each release tag, e.g. `git notes --ref semantic-release add -f -m '{"channels":["beta"]}' v2.0.0-beta.1`. If the release was also published in the default channel (usually `master`), then set the first channel to `null`, e.g. `git notes --ref semantic-release add -f -m '{"channels":[null, "beta"]}'`
|
||||
4. Push the local notes: `git push --force origin refs/notes/semantic-release`. The `--force` is needed after the rebase. Be careful.
|
||||
Reference in New Issue
Block a user