Steps
- Give
[package] in tb.toml a name, a version and a one-line description (keywords and a license help people find it):
[package]
name = "tb-greet"
version = "1.0.0"
description = "Friendly greetings."
license = "MIT"
keywords = ["greeting", "text"]
main = "lib.tb"
- Put the code people import in
lib.tb (or the file named by main). Mark public names with export and write a ## doc comment above each. Add a README.md: it becomes the package's page here.
- Test it:
tb test, tb fmt, tb check.
- Sign in below and make a token, then run
tb login and paste it. The token is stored in your user folder, readable only by you.
- Run
tb publish --dry-run to see exactly what would be uploaded, then tb publish.
$ tb login
$ tb publish
Checked tb-greet 1.0.0: 4 files, 3 KB zipped, entry lib.tb.
Uploading to https://code.tanisha.ceo/api/registry ...
Submitted tb-greet 1.0.0 for review.
The rules
- Review. The first version of a new package waits for an admin's approval before it is listed. After that, new versions from the package's owner are published at once.
- Names are 3 to 40 characters of lower-case letters, digits and
-. Standard library names (json, http, ...) and a few words like tb are reserved; names one letter away from an existing package get a closer look.
- Versions follow semantic versioning (
1.2.3, 2.0.0-beta.1) and can't be replaced once published. To take one back, yank it: tb yank tb-greet@1.0.1 --reason "breaks on Windows". Version ranges skip yanked versions; projects that pin one exactly still install it.
- Contents. A zip of up to 4 MB with
tb.toml, an entry .tb file and text files (.tb .toml .md .txt .json .csv .yml, LICENSE, ...), plus PNG, JPEG, GIF or WebP images for the README. No links, no hidden files, no programs. tb publish checks all of this before it uploads.
- At most 10 uploads an hour per account.