mirror of
https://github.com/oven-sh/bun
synced 2026-02-11 03:18:53 +00:00
c5005a37d7
## Summary This PR continues the work from #22107 to fix the `--tolerate-republish` flag implementation in `bun publish`. ### Changes: - **Pre-check version existence**: Before attempting to publish with `--tolerate-republish`, check if the version already exists on the registry - **Improved version checking**: Use GET request to package endpoint instead of HEAD, then parse JSON response to check if specific version exists - **Correct output stream**: Output warning to stderr instead of stdout for consistency with test expectations - **Better error handling**: Update test to accept both 403 and 409 HTTP error codes for duplicate publish attempts ### Test fixes: The tests were failing because: 1. The mock registry returns 409 Conflict (not 403) for duplicate packages 2. The warning message wasn't appearing in stderr as expected 3. The version check was using HEAD request which doesn't reliably return version info ## Test plan - [x] Fixed failing tests for `--tolerate-republish` functionality - [x] Tests now properly handle both 403 and 409 error responses - [x] Warning messages appear correctly in stderr 🤖 Generated with [Claude Code](https://claude.ai/code) --------- Co-authored-by: Claude Bot <claude-bot@bun.sh> Co-authored-by: autofix-ci[bot] <114827586+autofix-ci[bot]@users.noreply.github.com> Co-authored-by: Claude <noreply@anthropic.com> Co-authored-by: Dylan Conway <dylan.conway567@gmail.com>
123 lines
4.0 KiB
Markdown
123 lines
4.0 KiB
Markdown
Use `bun publish` to publish a package to the npm registry.
|
|
|
|
`bun publish` will automatically pack your package into a tarball, strip catalog and workspace protocols from the `package.json` (resolving versions if necessary), and publish to the registry specified in your configuration files. Both `bunfig.toml` and `.npmrc` files are supported.
|
|
|
|
```sh
|
|
## Publishing the package from the current working directory
|
|
$ bun publish
|
|
|
|
## Output
|
|
bun publish v$BUN_LATEST_VERSION (ca7428e9)
|
|
|
|
packed 203B package.json
|
|
packed 224B README.md
|
|
packed 30B index.ts
|
|
packed 0.64KB tsconfig.json
|
|
|
|
Total files: 4
|
|
Shasum: 79e2b4377b63f4de38dc7ea6e5e9dbee08311a69
|
|
Integrity: sha512-6QSNlDdSwyG/+[...]X6wXHriDWr6fA==
|
|
Unpacked size: 1.1KB
|
|
Packed size: 0.76KB
|
|
Tag: latest
|
|
Access: default
|
|
Registry: http://localhost:4873/
|
|
|
|
+ publish-1@1.0.0
|
|
```
|
|
|
|
Alternatively, you can pack and publish your package separately by using `bun pm pack` followed by `bun publish` with the path to the output tarball.
|
|
|
|
```sh
|
|
$ bun pm pack
|
|
...
|
|
$ bun publish ./package.tgz
|
|
```
|
|
|
|
{% callout %}
|
|
**Note** - `bun publish` will not run lifecycle scripts (`prepublishOnly/prepack/prepare/postpack/publish/postpublish`) if a tarball path is provided. Scripts will only be run if the package is packed by `bun publish`.
|
|
{% /callout %}
|
|
|
|
### `--access`
|
|
|
|
The `--access` flag can be used to set the access level of the package being published. The access level can be one of `public` or `restricted`. Unscoped packages are always public, and attempting to publish an unscoped package with `--access restricted` will result in an error.
|
|
|
|
```sh
|
|
$ bun publish --access public
|
|
```
|
|
|
|
`--access` can also be set in the `publishConfig` field of your `package.json`.
|
|
|
|
```json
|
|
{
|
|
"publishConfig": {
|
|
"access": "restricted"
|
|
}
|
|
}
|
|
```
|
|
|
|
### `--tag`
|
|
|
|
Set the tag of the package version being published. By default, the tag is `latest`. The initial version of a package is always given the `latest` tag in addition to the specified tag.
|
|
|
|
```sh
|
|
$ bun publish --tag alpha
|
|
```
|
|
|
|
`--tag` can also be set in the `publishConfig` field of your `package.json`.
|
|
|
|
```json
|
|
{
|
|
"publishConfig": {
|
|
"tag": "next"
|
|
}
|
|
}
|
|
```
|
|
|
|
### `--dry-run`
|
|
|
|
The `--dry-run` flag can be used to simulate the publish process without actually publishing the package. This is useful for verifying the contents of the published package without actually publishing the package.
|
|
|
|
```sh
|
|
$ bun publish --dry-run
|
|
```
|
|
|
|
### `--tolerate-republish`
|
|
|
|
The `--tolerate-republish` flag makes `bun publish` exit with code 0 instead of code 1 when attempting to republish over an existing version number. This is useful in automated workflows where republishing the same version might occur and should not be treated as an error.
|
|
|
|
```sh
|
|
$ bun publish --tolerate-republish
|
|
```
|
|
|
|
Without this flag, attempting to publish a version that already exists will result in an error and exit code 1. With this flag, the command will exit successfully even when trying to republish an existing version.
|
|
|
|
### `--gzip-level`
|
|
|
|
Specify the level of gzip compression to use when packing the package. Only applies to `bun publish` without a tarball path argument. Values range from `0` to `9` (default is `9`).
|
|
{% bunCLIUsage command="publish" /%}
|
|
|
|
### `--auth-type`
|
|
|
|
If you have 2FA enabled for your npm account, `bun publish` will prompt you for a one-time password. This can be done through a browser or the CLI. The `--auth-type` flag can be used to tell the npm registry which method you prefer. The possible values are `web` and `legacy`, with `web` being the default.
|
|
|
|
```sh
|
|
$ bun publish --auth-type legacy
|
|
...
|
|
This operation requires a one-time password.
|
|
Enter OTP: 123456
|
|
...
|
|
```
|
|
|
|
### `--otp`
|
|
|
|
Provide a one-time password directly to the CLI. If the password is valid, this will skip the extra prompt for a one-time password before publishing. Example usage:
|
|
|
|
```sh
|
|
$ bun publish --otp 123456
|
|
```
|
|
|
|
{% callout %}
|
|
**Note** - `bun publish` respects the `NPM_CONFIG_TOKEN` environment variable which can be used when publishing in github actions or automated workflows.
|
|
{% /callout %}
|