CLI
Two things are published to npm:
@tostada-ui/format— regenerates your artifacts from a library file. Apache-2.0.@tostada-ui/scan— measures the front-end debt in a React repository.
Everything else — the editor, drift reporting, applying a system to a codebase — is the product rather than something you install. Reading a scan report is too: the scanner runs anywhere, and the report it produces is read in an account.
@tostada-ui/format — regenerate your artifacts
npx @tostada-ui/format export
npx @tostada-ui/format docs
Two verbs. Both read a tostada.json — the file the app exports — and write
files. Neither needs the app, an account, or a network connection.
| Command | Writes | Default --out |
|---|---|---|
export |
The committable bundle: tokens.css, theme.css, layout-principles.md, design-system.json, AGENTS.md, README.md |
./src/design |
docs |
The offline documentation site — HTML that opens from file:// |
./design-docs |
Both default to reading ./tostada.json; --from and --out override, and
--help works on either.
Both run entirely offline and write only where you point them. Nothing is uploaded and no network call is made — unlike the scan below, which sends its finished report. The distinction is the point: regenerating your own artifacts is something you do alone.
Why drift reporting is not here
tostada diff is deliberately absent. Comparing two snapshots to report what
changed is auditing, and auditing is the product — so it lives in the app
rather than in the open package.
Typing it gives you a message saying so rather than "unknown command", because anyone typing it has read older documentation and deserves to be told where the feature went instead of hunting for a typo.
See tracking drift for what drift reporting does and how to get it.
Why the CLI ships inside the format package
It is a thin wrapper over that package's own generators. A separate package would carry its own version and could skew from the library it wraps — and a CLI that regenerates your artifacts with a different generator than the one your documentation describes is the one failure this arrangement cannot afford.
@tostada-ui/scan — the scan
npx @tostada-ui/scan
Run it at the root of a React app and it measures the front-end debt: what is hardcoded, how often, and which components are near-duplicates of each other. It prints your score straight away and sends the finished report to a one-time link. No account is needed to run it; a free account opens the report.
Your code never leaves your machine. The scan reads your files as text and
never executes them — not your components, not tailwind.config.js, not
tsconfig.json. What is uploaded is the report itself: values, counts and
paths. No file contents, no environment detail, no usage pings.
If the upload fails you still get your number, and the report waits beside your output:
npx @tostada-ui/scan --resend
A report nobody claims is deleted after 30 days.
What a free account sees
Your score and grade, the category counts, and the top findings with their locations — real substance you can act on and verify. Pro opens every finding, the accessibility section, the remediation plan, and export.
The report you claimed was always stored complete, so upgrading opens that report rather than starting a new one.
See scan reports.
Not a CLI
Applying a design system to a repository you already ship from, and generating a clean codebase from one, run as engines during an engagement rather than as tools you install — they rewrite code, so they are delivered with someone watching the diff. See using Tostada in your codebase.
The editor is the web app. The CLI never edits a library; it reads one and writes artifacts from it.
Repository scripts
For anyone working in the Tostada repository itself. These are not published and are not part of the product.
| Script | What it does |
|---|---|
npm run dev |
The app on :5173 |
npm run dev:preview-host |
The preview sandbox on :5179 |
npm run build |
Type-check, build, then build the CLI bundles |
npm run test |
Unit and component tests |
npm run e2e |
End-to-end tests |
npm run lint |
ESLint across the repository |
npm run sync:shadcn |
Re-fetch the component registry, then merge locally authored components, demos and blocks |
npm run sync:previews |
Recapture component previews for the offline docs folder |
npm run deploy:app · deploy:staging |
Deploy the built app |
dev and dev:preview-host must both be running for the Components surface to
render previews.
Docs are built separately, from web/: npm run build:docs for one pass,
npm run watch:docs while iterating.
Why these two are open
Reading what Tostada produced is open; authoring and auditing are the product. A library file you exported is yours, and everything needed to turn it back into CSS and documentation ships under Apache-2.0 — so your system survives without us. Drift reporting sits the other side of that line because it is a judgement about your codebase, not a rendering of your file.