chore(ui): install @plugpress/ui from npm instead of a GitHub tag - #105
Merged
Conversation
`@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
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What
@plugpress/uimoves fromgithub:plugpressco/plugpress-ui#v0.11.3to^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, afilesallowlist,sideEffectsfor 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:
^0.12.0← already on the registrygithub:…#v0.11.3github:…#v0.11.2github:…#v0.10.4Four 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.mdwarned that "changing the git ref and runningnpm installdoes not re-resolve it —rm -rf node_modules/@plugpress/uifirst". 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 ownfleet:bump/fleet:releaserewrite every consumer back to a GitHub tag (cmdBumpsets${REPO}#v${version}unconditionally, andreleasenever runsnpm 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
.d.tsand produced a false negative on every icon; worth knowing that's not a reliable check.npm run lint:jsclean,npm run buildclean,composer test577 green,composer lint0 errors.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 installcorrectedpackage-lock.json's ownversionfrom1.0.0to1.0.0-rc3, wherepackage.jsonalready was — the lockfile had drifted. Four of the five places the version lives now agree, with readme'sStable tagcorrectly still at1.0.0.🤖 Generated with Claude Code
https://claude.ai/code/session_01GkZr73cqaSesHRDG89Yy8S