deps(ui-kit): publish the stranded recharts v3 migration, and guard the class - #9977
Conversation
…at it rewrote @loopover/ui-kit has been stuck on 1.3.0 while carrying an unreleased, user-visible change: `chore(deps): migrate recharts to v3 across all three workspaces (#8610)` rewrote src/components/chart.tsx and shipped to nobody. release-please would never cut that release on its own. It decides whether a component HAS a release before it decides how much to bump, and that decision keeps only "user facing" commits -- those whose type is not `hidden: true` in changelog-sections. `chore` is hidden here, so its own dry run says: ✔ Building candidate release pull request for path: packages/loopover-ui-kit ✔ No user facing commits found since 0fa52ed... - skipping This is deliberately typed `deps` -- the repo's own non-hidden "Dependencies" section -- because that is what the release publishes: the recharts v3 migration. `Release-As:` was the other candidate and does not work here; the skip above is on an empty changelog and runs after the version is computed, so a footer on a hidden-type commit is still skipped. The diff is the coverage that migration never had. chart.tsx had NO tests at all, so the load-bearing parts of a major-version rewrite were resting on the type-checker: that payload/label now arrive through context rather than as Tooltip props, that config labels (not raw dataKeys) are what a reader sees, that an inactive or empty payload paints nothing, and that both arms of ChartConfig's color/theme union reach the stylesheet. ResponsiveContainer is replaced with a passthrough for these tests and nothing else is: it measures through a ResizeObserver that never resolves under jsdom, so it renders nothing and discards its children -- which would have made the "renders nothing" assertions pass for entirely the wrong reason. Mutation-tested: forcing the tooltip to always render, inverting ChartStyle's empty-config guard, and dropping useChart's provider check each fail.
…er release The recharts v3 migration rewrote packages/loopover-ui-kit/src/components/ chart.tsx under a `chore(deps):` subject. It merged, CI was green, and the package sat on 1.3.0 with that change unpublished. Nothing was red; the only symptom was a drift issue whose checklist said "merge the release-please PR" for a PR that could never exist. release-please filters commits whose type is `hidden: true` in changelog-sections BEFORE building a release candidate, so a hidden type on published source strands the change. Note this is not the same question as how much to bump: asked directly, DefaultVersioningStrategy turns a `chore` into a patch (1.3.0 -> 1.3.1). It simply never gets asked. That gap is why this has to be checked rather than reasoned about. The config is the source of truth, not a list here. Both the released package paths and the hidden-type set are read out of release-please-config.json, so adding a package or unhiding a type moves the check with it. Test files are excluded even though they sit under src/. Every package excludes src/**/*.test.* from its build and none list tests in `files`, so a test is not published -- and `test:` is itself hidden, which makes `test(pkg): add a test` the most common hidden-type commit there is. Flagging it would fire the guard on the ordinary case and get the guard switched off. Found by running the guard against the very commit that added it. A `Release-As:` footer is exempt: that is release-please's own mechanism for forcing a version, so a commit using it has already answered the question -- and a guard that rejects the remedy its own message recommends is a broken guard.
|
Tip ✅ LoopOver review result - approve/merge recommendedReview updated: 2026-07-31 01:10:25 UTC
Review summary Nits — 5 non-blocking
Decision drivers
Context & advisory signals — never blocks the verdict
Linked issue satisfactionPartially addressed Review context
Contributor next steps
Signal definitions
🧪 Chat with LoopOverAsk LoopOver a question about this PR directly in a comment — grounded only in the same cached, public-safe facts shown above, never a new claim.
Full command reference: https://loopover.ai/docs/loopover-commands 🧪 Experimental — new and may change. Visual preview
Click any thumbnail to open the full-size screenshot. Before = production · After = this PR's preview deploy. Scroll preview
A short scroll-through clip (desktop) — click either thumbnail to open the full animation. Evidence for scroll-linked behavior a single screenshot can't show. 🟩 Safe / merged · 🟦 Advisory · 🟨 Held for review · 🟥 Blocked / closed 💰 Earn for open-source contributions like this. Gittensor lets GitHub contributors earn for the work they already do — register to start earning →. Checked by LoopOver, a quiet PR intelligence layer for OSS maintainers.
|
|
Superagent didn't find any vulnerabilities or security issues in this PR. |
Deploying with
|
| Status | Name | Latest Commit | Preview URL | Updated (UTC) |
|---|---|---|---|---|
| ✅ Deployment successful! View logs |
loopover-ui | 6be3f90 | Commit Preview URL Branch Preview URL |
Jul 31 2026, 12:48 AM |
Bundle ReportBundle size has no change ✅ |
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## main #9977 +/- ##
=======================================
Coverage 91.88% 91.88%
=======================================
Files 928 928
Lines 113722 113722
Branches 27436 27436
=======================================
Hits 104489 104489
Misses 7936 7936
Partials 1297 1297
Flags with carried forward coverage won't be shown. Click here to find out more. |
…9988) The tests added in #9977 were never run through prettier, and `ui:lint` runs `format:check` across the ui-kit workspace as part of `test:ci` -- so main has been failing lint since that merge, and every PR inherits it. My regression, and the same cause as the last one: I ran a checker subset (typecheck, dead-exports, the pack test, the ui-kit suite) and not `ui:lint`, which is the one that would have caught it. No behaviour changes -- prettier reflow only, and the 10 tests still pass.
1 participant
Why ui-kit is stuck, and why it is not a stale issue
@loopover/ui-kit has been on 1.3.0 while carrying an unreleased, user-visible change.
chore(deps): migrate recharts to v3 across all three workspaces (#8610)rewrotepackages/loopover-ui-kit/src/components/chart.tsx— real shipped code — and it has shipped to nobody.Unlike its sibling #9875 (which I closed: engine is already past it at 3.18.0), this one is structural. release-please will never cut this release on its own. Its own dry run, run against this repo:
"User facing" means the commit's type is not
hidden: trueinchangelog-sections.choreis hidden here, so the commit is filtered out before a release candidate is built.Worth stating precisely, because it is not what I first assumed: this is not a question of how much to bump. Asked directly,
DefaultVersioningStrategyturns that same commit into a patch:It simply never gets asked. That gap between "would bump" and "never considered" is why this needed checking against the real tool rather than reasoning.
Two commits
1.
deps(ui-kit):— cuts the releaseDeliberately typed
deps, this repo's own non-hidden Dependencies section, because that is exactly what the release publishes: the recharts v3 migration.Release-As:was the other candidate and does not work here. The skip above ischangelogEmpty(releaseNotesBody)atstrategies/base.js:168, which runs after the version is computed — so aRelease-Asfooter on a hidden-type commit still produces an empty changelog and is still skipped.The diff is the coverage that migration never had.
chart.tsxhad zero tests, so the load-bearing parts of a major-version rewrite were resting on the type-checker alone:payload/labelnow arrive through context, not as Tooltip props — the v3 change itselflabels, not rawdataKeys, are what a reader sees (the most likely silent regression: it still "renders fine")!active || !payload?.lengthis two conditionsChartConfig'scolor/themeunion reach the stylesheetuseChartthrows its named error outside a providerResponsiveContaineris replaced with a passthrough and nothing else is: it measures through a ResizeObserver that never resolves under jsdom, so it renders nothing and discards its children — which would have made the "renders nothing" assertions pass for entirely the wrong reason. (I hit exactly that while writing them.)Mutation-tested — each fails, baseline restored green:
ChartStyle's empty-config guarduseChart's provider check2.
ci(release):— stops it recurringA check that fails when a commit changes a released package's published source under a type release-please treats as invisible.
release-please-config.json, so adding a package or unhiding a type moves the guard with it.src/. Every package excludessrc/**/*.test.*from its build and none list tests infiles, so a test is not published — andtest:is itself hidden, makingtest(pkg): add a testthe single most common hidden-type commit there is. Flagging it would fire the guard on the ordinary case and get it switched off. I found this by running the guard against the very commit that added it.Release-As:is exempt — a guard that rejects the remedy its own failure message recommends is a broken guard.chore!:) are exempt; breaking is user-facing whatever the type.24 unit tests, including the historical recharts commit asserted against the real config, so unhiding
choreor renaming a package path cannot leave the guard quietly asserting nothing.Note on merge order
This targets
mainbut CI will stay red until #9976 lands — an unrelated repo-wide breakage where anode_modulescache hit skipspostinstall, soapps/loopover-uitypechecks against acollections/*module that was never generated. Not caused by this PR; it fails every PR right now.Verification
typecheck,checkers-wired:check,dead-source-files:check,dead-exports:check,import-specifiers:check,coverage-boltons:check,release-commit-parsing:check,validate:no-hand-written-jsgreen2 commit(s) checked, none would be stranded)test:ui-kit-packgreen; ui-kit suite 53 tests passed (was 43)Closes #9937