There is a deck for this now, and a longer one specifically about the package manager: The SCUA package manager. This post is the written version of the parts people ask about most.
scua-pkg is a separate binary with its own repository
and release stream. The scua toolchain dispatches to it the
way git dispatches to subcommands, so scua add works when
it is on your PATH and running a script never requires it. Every fetch,
TLS and registry path lives outside the runtime, which is what keeps a
build of scua with no network code a supported
configuration.
#Identity is a hash, not a name
A package's identity is a content hash you can recompute from the
bytes you have. Not a name, not a version string, not a signature from
someone you have to trust. If two people fetch
@acme/pathfind and get different bytes, the hashes differ
and the tools say so, rather than one of them silently getting something
else.
That is also what makes verify meaningful. It re-checks
every hash in the store and in your vendored tree against what the
lockfile committed to, so tampering after the fact shows up as a
mismatch rather than as nothing at all.
#Nothing runs at install
No package can execute code at resolve or install time. There is no install script, no build hook, no post-fetch step. Adding a dependency copies bytes and writes a lockfile; it does not run anything the author wrote.
This rules out the most common supply-chain attack outright rather
than mitigating it. It also means add and
vendor are safe to run on a machine you care about, which
is the point.
#Scopes are sealed
@acme resolves in acme's registry and nowhere else. A
scope is bound to its registry, so the confusion attack is a
configuration error you get told about rather than a silent
substitution. Publishing @acme/internal-thing to a public
index and waiting for someone's resolver to prefer it does not work
here.
#Versions are
immutable, and yank tombstones
A published version's bytes never change. yank marks a
version as withdrawn; it does not delete it. History cannot be quietly
rewritten, and a build that pinned a yanked version keeps working while
telling you it is yanked.
#The verbs that explain themselves
A resolver that cannot show its work is asking to be believed. So
alongside add, vendor, verify and
run there are why (what pulled this in),
diff (what changed between two resolutions),
sbom (what is actually in this tree) and
search.
The trust pair, trust and audit, compute
verdicts on your machine from evidence you chose to
import. There is no central authority whose badge you are asked to
accept.
#Where it stands
Every verb in the spec's table is implemented, along with the trust machinery and the docs. Resolution uses minimal version selection.
What does not exist yet is a public registry. The plan there is deliberately small: a static CDN-served index, and a signed transparency log that exists from the very first public publish, because first-seen history is the one thing that cannot be retrofitted. Until then the tool is exercised against directory registries, and since a directory is a registry, that is most of the product already.
One compatibility note if you are on 0.16: scua-pkg
refuses a toolchain newer than the one it knows about, and it does not
know about 0.16 yet. Those commands stay refused until a
scua-pkg release supports it. A project that already has
its deps/ runs normally.