→ Keeping a project current is one command, because every Salty package ships together.
Updates
Salty is pre-1.0, and every @salty-css/* package ships on the same version number. So keeping a project current isn't a per-package chore — it's one command, and that command is most of what this page has to say today.
It'll grow. Once there are breaking changes that need a written path through them, the codemods and the this-moved-here's-where-it-went notes land on this page. Worth separating from its neighbour: Migration is about moving onto Salty from something else, this one is about moving from one version of Salty to the next.
Updating the packages
update — alias up — bumps every Salty package in your package.json together:
npx salty-css up # everything to latest
npx salty-css up 0.4.2 # or pin them all to one versionTogether is the important word. @salty-css/core, @salty-css/react and your bundler plugin are built and released as a set, and mixing versions across them produces confusing failures rather than clear ones — a component that renders with no styles, a token path that type-checks and compiles to nothing. Bumping one of them by hand is the shortest route to an afternoon you hadn't planned on.
| Argument / flag | What it does |
|---|---|
[version] | The version to move to. Defaults to latest. |
--dir <dir> | Project directory to rebuild once the install finishes. |
-y, --yes | Skip the confirmation prompt. |
--legacy-peer-deps | Passed straight through to npm. Not recommended — it quiets a version conflict rather than resolving one. |
One thing to know about what happens after the install: saltygen/ is a build artifact, regenerated from scratch on every compile, so it wants a fresh build from the new compiler. --dir takes care of it, and so does starting your dev server.
If you're not sure what you're actually running, npx salty-css --version prints the CLI version plus every Salty package in your package.json. That's also the output worth pasting in when you open an issue.
Where the release notes live
Every release is written up on GitHub Releases — what changed, what moved, and anything you need to do on your side. That's the canonical list, and this page won't try to duplicate it.
The honest framing of pre-1.0: minor APIs can still move between releases. Pin your versions rather than floating on a caret, read the notes before you bump, and you'll be fine.