import Publish from "/snippets/cli/publish.mdx";

bun publish packt Ihr Paket automatisch in ein Tarball, entfernt Katalog- und Workspace-Protokolle aus der package.json (löst bei Bedarf Versionen auf) und veröffentlicht in die in Ihren Konfigurationsdateien angegebene Registry. Sowohl bunfig.toml- als auch .npmrc-Dateien werden unterstützt.

## Veröffentlicht das Paket aus dem aktuellen Arbeitsverzeichnis
bun publish

bun publish v1.3.3 (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

Alternativ können Sie Ihr Paket separat packen und veröffentlichen, indem Sie bun pm pack gefolgt von bun publish mit dem Pfad zum Ausgabe-Tarball verwenden:

bun pm pack
...
bun publish ./package.tgz

NOTE

`bun publish` führt keine Lifecycle-Skripte (`prepublishOnly/prepack/prepare/postpack/publish/postpublish`) aus, wenn ein Tarball-Pfad angegeben wird. Skripte werden nur ausgeführt, wenn das Paket von `bun publish` gepackt wird.

--access

Das --access-Flag kann verwendet werden, um die Zugriffsebene des zu veröffentlichenden Pakets festzulegen. Die Zugriffsebene kann public oder restricted sein. Pakete ohne Scope sind immer öffentlich, und der Versuch, ein Paket ohne Scope mit --access restricted zu veröffentlichen, führt zu einem Fehler.

bun publish --access public

--access kann auch im publishConfig-Feld Ihrer package.json festgelegt werden.

{
  "publishConfig": {
    "access": "restricted"
  }
}

--tag

Legt das Tag der zu veröffentlichenden Paketversion fest. Standardmäßig ist das Tag latest. Die erste Version eines Pakets erhält immer das latest-Tag zusätzlich zum angegebenen Tag.

bun publish --tag alpha

--tag kann auch im publishConfig-Feld Ihrer package.json festgelegt werden.

{
  "publishConfig": {
    "tag": "next"
  }
}

--dry-run

Das --dry-run-Flag kann verwendet werden, um den Veröffentlichungsprozess zu simulieren, ohne das Paket tatsächlich zu veröffentlichen. Dies ist nützlich, um den Inhalt des veröffentlichten Pakets zu überprüfen, ohne es tatsächlich zu veröffentlichen.

bun publish --dry-run

--tolerate-republish

Beendet mit Code 0 statt 1, wenn die Paketversion bereits existiert. Nützlich in CI/CD, wo Jobs erneut ausgeführt werden können.

bun publish --tolerate-republish

--gzip-level

Gibt die beim Packen des Pakets zu verwendende Gzip-Komprimierungsstufe an. Gilt nur für bun publish ohne ein Tarball-Pfad-Argument. Werte reichen von 0 bis 9 (Standard ist 9).

--auth-type

Wenn Sie 2FA für Ihr npm-Konto aktiviert haben, fordert bun publish Sie zur Eingabe eines Einmalpassworts auf. Dies kann über einen Browser oder die CLI erfolgen. Das --auth-type-Flag kann verwendet werden, um der npm-Registry mitzuteilen, welche Methode Sie bevorzugen. Die möglichen Werte sind web und legacy, wobei web der Standard ist.

bun publish --auth-type legacy
...
This operation requires a one-time password.
Enter OTP: 123456
...

--otp

Gibt ein Einmalpasswort direkt an die CLI weiter. Wenn das Passwort gültig ist, wird die zusätzliche Aufforderung für ein Einmalpasswort vor der Veröffentlichung übersprungen. Beispielverwendung:

bun publish --otp 123456

NOTE

`bun publish` respektiert die `NPM_CONFIG_TOKEN`-Umgebungsvariable, die bei der Veröffentlichung in GitHub Actions oder automatisierten Workflows verwendet werden kann.