Publishing

Publishing is designed to be a non-event. If your package builds, tests pass and the version is valid, prism publish does the rest — including building the docs and running the linter for you.

Before you publish

A package needs:

1. A prism.toml manifest with name, version and license.
2. A src/lib.prism entry point (or a src/bin/ for binaries).
3. At least one test. The registry refuses packages with zero tests — a small nudge that matters more than it seems.

The command

prism publish

The flow, in order:

1. Runs prism test.
2. Checks the version against the previous release.
3. Builds the package for all supported targets.
4. Uploads the tarball, checksums and generated docs.
5. Prints the public URL.

Namespacing

Package names may be namespaced by user:

name = "ada/http"

Unnamespaced names are first-come, first-served. Namespaced ones are yours to manage and can be transferred.

Private packages

For proprietary code, publish a private package:

[package]
private = true

Private packages require an access token and are only fetchable by your projects. They behave identically otherwise — same lockfile, same checksums, same reproducible builds.

Yanking and fixing

Note: prism yank is planned for a future release and is not yet in the v0.1.0 CLI.

Today, fixing a bad release means publishing a patch. The registry keeps every version, so existing lockfiles keep resolving, and new resolutions pick up the fixed release. Patches are the preferred fix: fix loudly, re-release quickly.

Tip: publish early and often. The registry keeps every version forever — your history is your package’s documentation.