Skip to content

chore(ui): install @plugpress/ui from npm instead of a GitHub tag - #105

Merged
ifahimreza merged 1 commit into
mainfrom
chore/plugpress-ui-npm
Aug 16, 2026
Merged

chore(ui): install @plugpress/ui from npm instead of a GitHub tag#105
ifahimreza merged 1 commit into
mainfrom
chore/plugpress-ui-npm

Conversation

@ifahimreza

Copy link
Copy Markdown
Contributor

What

@plugpress/ui moves from github:plugpressco/plugpress-ui#v0.11.3 to ^0.12.0, resolved from the public npm registry.

Why

The package has been published to npm since 0.12.0 (13 Aug) and its packaging is correct — dual ESM/CJS exports, types, a files allowlist, sideEffects for CSS, publishConfig.access: public, React as a peer dep. Saddle was still installing it as a git dependency.

The fleet was split four ways across six plugins:

plugin before
waggle, inbees ^0.12.0 ← already on the registry
saddle github:…#v0.11.3
loggle github:…#v0.11.2
mailyard, knovia github:…#v0.10.4

Four versions of a design system whose entire premise is that they look the same.

The lockfile now carries an integrity hash instead of a commit SHA. That's the part that actually matters — a git ref is not content-addressed, so a retagged release would install different bytes under the same lockfile entry.

The npm trap is retired

CLAUDE.md warned that "changing the git ref and running npm install does not re-resolve it — rm -rf node_modules/@plugpress/ui first". That was never a quirk of npm; it was a property of git deps, and it goes away with the pin.

Replaced with the hazard that is still real: plugpress-ui's own fleet:bump / fleet:release rewrite every consumer back to a GitHub tag (cmdBump sets ${REPO}#v${version} unconditionally, and release never runs npm publish). Running those from that repo would silently undo this. That tooling needs fixing there before it's pointed at Saddle again — and it would equally revert waggle and inbees today.

Verified, not assumed

  • All 53 symbols Saddle imports resolve against published 0.12.0 — checked against the real runtime export list. My first attempt grepped the rollup .d.ts and produced a false negative on every icon; worth knowing that's not a reliable check.
  • npm run lint:js clean, npm run build clean, composer test 577 green, composer lint 0 errors.
  • Driven in a real Playground install: Dashboard and Permissions render correctly; the tier selector recomputes live (66 tools at admin → 36 at read with "30 need a higher level"); the save bar shows the reconnect warning; console clean on a fresh load.

The bundle gains 1.2KB of CSS — the 0.11.4/0.11.5 foundation-and-tokens work arriving. Cosmetic, and nothing regressed on the screens above.

Not a version bump

npm install corrected package-lock.json's own version from 1.0.0 to 1.0.0-rc3, where package.json already was — the lockfile had drifted. Four of the five places the version lives now agree, with readme's Stable tag correctly still at 1.0.0.

🤖 Generated with Claude Code

https://claude.ai/code/session_01GkZr73cqaSesHRDG89Yy8S

`@plugpress/ui` has been published to the public npm registry since 0.12.0
(2026-08-13), but Saddle was still installing it as a git dependency pinned to
`#v0.11.3`. Two consumers in the fleet (waggle, inbees) had already moved to a
registry range; Saddle, loggle, mailyard and knovia had not, leaving six
plugins spread across four versions of a design system whose entire premise is
that they look the same.

Now `^0.12.0`, resolved from the registry. The lockfile carries an integrity
hash instead of a commit SHA, which is the part that actually matters: a git
ref is not content-addressed, and a retagged release would install different
bytes under the same lockfile entry.

This also retires the npm trap documented in CLAUDE.md — "changing the git ref
and running npm install does not re-resolve it; rm -rf node_modules first".
That was never a quirk of npm, it was a property of git deps. A registry range
re-resolves normally. The note is replaced with the one thing that is still
true and is now the actual hazard: `plugpress-ui`'s own `fleet:bump` and
`fleet:release` still rewrite every consumer to a GitHub tag, so running those
from that repo would silently undo this. That tooling needs fixing there before
it is pointed at Saddle again.

Verified rather than assumed. All 53 symbols Saddle imports resolve against the
published 0.12.0 (checked against the real runtime export list, not a grep of
the .d.ts — the first attempt at that gave a false negative on every icon).
`npm run lint:js` clean, `npm run build` clean, and the admin UI driven in a
Playground install: Dashboard and Permissions render correctly, the tier
selector recomputes live (66 tools at admin, 36 at read with "30 need a higher
level"), the save bar shows the reconnect warning, and the console is clean on
a fresh load.

The bundle grew 1.2KB of CSS, which is the 0.11.4/0.11.5 foundation-and-tokens
work arriving — cosmetic, and nothing regressed on the screens above.

Not a version bump: `npm install` corrected package-lock's own `version` field
from 1.0.0 to 1.0.0-rc3, where package.json already was. The lockfile had
drifted; four of the five places the version lives now agree, with readme's
Stable tag correctly still at 1.0.0.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01GkZr73cqaSesHRDG89Yy8S
@ifahimreza
ifahimreza merged commit d0bb7d3 into main Aug 16, 2026
1 of 7 checks passed
@ifahimreza
ifahimreza deleted the chore/plugpress-ui-npm branch August 16, 2026 11:36
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant