A version written into a manifest is written into every manifest that wants it,
which is how eslint came to exist in a hundred and four forms across this estate
and how a package came to resolve twice at run time. The catalog moves the number
out of the manifest: a manifest names the package, the workspace names the
version.
Four are held below their latest because the newer release cannot be used, and
the reason is recorded rather than the version alone: @noble/hashes 2 renamed
every subpath the web3 stack imports, @splinetool/runtime 2 depends on a package
that was never published, @dynamic-labs 5.4.1 the same, and react-resizable-panels
3 points its types condition at the bundle.
Co-authored-by: Hanzo Dev <[email protected]>
Every dependency on a @hanzo/@luxfi/@zooai package now names the same version
across the repo: a catalog entry where pnpm supports one, an exact pin where it
does not, and a range only where a peer genuinely means one.
pnpm itself is pinned too — the estate ran eighteen different versions, five of
them too old to read a catalog.
Co-authored-by: Hanzo Dev <[email protected]>
Thirty-one manifests asked for @hanzo/font ^1.9.1 while the lockfile still
resolved 1.8.0, 1.8.2 and 1.8.12, so pnpm install --frozen-lockfile — which is
every workflow under .hanzo — refused to install anything at all.
The floor is 1.9.2 rather than 1.9.1 because 1.9.1's zen.css carries the
@font-face rules and nothing else: the :root block binding --font-zen-sans and
--font-zen-mono is absent, and a sheet reading either property gets an invalid
value and the OS default without saying so. 1.9.2 publishes them again.
Twelve example layouts imported `ZenSans` from `@hanzo/font/sans`, a name
the package stopped exporting at 1.9.0 — the family is called Zen, so the
binding is `Zen`. Every one of those layouts would fail to resolve the
import against a current install, and the `^1.8.x` ranges they pinned kept
resolving to the old export instead of surfacing it.
zeekayandHanzo Dev