chore(deps): update non-major dependencies, pin happy-dom (nuxt/ui@ebd4adf) - #551
Merged
Merged
Conversation
IgorShevchik
force-pushed
the
sync/nuxt-2e8f533d
branch
from
September 8, 2026 07:28
1dff223 to
0fb7c2f
Compare
IgorShevchik
force-pushed
the
sync/nuxt-ebd4adfc
branch
from
September 8, 2026 07:28
d137554 to
473499b
Compare
…d4adf) Every package this fork shares with upstream in the same section sat at upstream's exact pre-image, checked package by package rather than inferred from `dep-parity.json` being green. Six of upstream's names are absent here, and the `@internationalized/*` peer ranges are `^3.0.0` on both sides — upstream did not touch those either. `playgrounds/demo` is ours alone and declares four of the bumped packages. Two sat at upstream's pre-image; the other two had drifted behind *this fork's own root* — `@ai-sdk/vue` `^4.0.77` against our `^4.0.85`, `ai` `^7.0.77` against `^7.0.85`. Brought up with the rest. That is the "one-time divergence becomes permanent" failure `dep-parity.json` describes, and demo is invisible to that file because upstream has no counterpart to compare against. `happy-dom` is NOT taken, and the reason outlives this commit. Upstream goes `^20.12.0` → `^20.14.0`. Taking it turns 1450 tests and 136 snapshots red across 64 files: TypeError: 'defineProperty' on proxy: trap returned falsish for property '__v_skip' Vue's `markRaw` against a happy-dom proxy, raised from reka's `Presence` watcher. Isolated rather than guessed — with every other bump applied and happy-dom alone moved back, the suite is green — then bisected: 20.12.0 passes; 20.12.1, 20.12.2, 20.13.0, 20.13.1 and 20.14.0 all fail. The declared range was `^20.12.0`, which admits every one of those. It worked only because the lockfile happened to hold 20.12.0 — any fresh resolution would have taken 20.14.0 and reddened the suite with no source change to point at. `~20.12.0` is not enough either, since 20.12.1 already breaks. So the declaration becomes an exact pin and the reason goes in `dep-parity.json`'s `exceptions`, where the next deps port will read it. This closes a landmine rather than adding a restriction. Upstream ships `^20.14.0` and is presumably green, so whatever differs is on our side — reka's version or the vitest environment. Finding it is not something a dependency-bump port can do; recorded for a follow-up. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01JS8ypVfQSFzYVZzkTHhURb
IgorShevchik
force-pushed
the
sync/nuxt-ebd4adfc
branch
from
September 8, 2026 07:37
473499b to
4e1e0f4
Compare
`2e8f533d` went in with `pending-merge` in both fields, as PORTING.md §6 step 4 requires — the entry is written with the port, before its PR has a number or a squash SHA. That PR has now merged: - `2e8f533d` → #550 / `bf25c1eb` Carried here rather than in its own bookkeeping PR, which is the mechanism §6 step 4 describes: the next port in a run reconciles the previous entry, and only the last entry needs a PR of its own. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01JS8ypVfQSFzYVZzkTHhURb
IgorShevchik
added a commit
that referenced
this pull request
Sep 8, 2026
…2d4782b) (#552) * fix(InputNumber): work uncontrolled with only a default value (nuxt/ui@2d4782b) `useVModel` kept its own copy of the value and that copy was bound to `NumberFieldRoot`'s `model-value`. With only a `defaultValue` and no `v-model`, reka has internal state of its own and the two disagreed — the field stepped off the wrapper's copy instead of off reka's, so an uncontrolled `InputNumber` did not increment at all. Removing the wrapper alone trades that for a different bug, which is why the fix has a second half. Reka writes `update:modelValue` on every write — blur, Enter, stepping at a bound — whether or not the value moved, and with `useVModel` gone nothing absorbs those. So `onUpdate` gains an equality guard and emits by hand, and `useForwardProps` loses its `emits` argument for the same reason: the root must not re-emit what `onUpdate` now owns. The guard's second clause is not redundant. `undefined` and `null` are different values but the same emptiness — the `.optional` modifier produces the first, a caller supplies the second. Verified against the pre-image rather than assumed: with the component reverted and upstream's four tests kept, all four fail; with the port, all pass. The defect was live here. Mutations separate the two halves — dropping the emit turns 14 red, dropping the guard turns 6 red, and keeping only `value === props.modelValue` while dropping the `== null` clause turns 2 red. That last one shows the clause is load-bearing rather than defensive padding no test would miss. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01JS8ypVfQSFzYVZzkTHhURb * chore(sync): reconcile the #551 ledger entry `ebd4adfc` went in with `pending-merge` in both fields, as PORTING.md §6 step 4 requires. That PR has now merged: - `ebd4adfc` → #551 / `d57db682` Carried here rather than in its own bookkeeping PR, per §6 step 4: the next port in a run reconciles the previous entry, and only the last entry needs a PR of its own. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01JS8ypVfQSFzYVZzkTHhURb --------- Co-authored-by: Shevchik Igor <noreply@anthropic.com>
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
2 participants
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.
Port of
nuxt/ui@ebd4adfc— second of ten in this run.What applies
Every shared package sat at upstream's exact pre-image — checked package by package, not inferred from
dep-parity.jsonbeing green.package.json@internationalized/date^3.12.4,@internationalized/number^3.6.8,motion-v^2.4.2,ai^7.0.93,eslint^10.10.0docs/package.json@ai-sdk/vue^4.0.93,ai^7.0.93,joi^18.2.8,maska^3.2.1,motion-v^2.4.2playgrounds/nuxt@ai-sdk/vue^4.0.93,@internationalized/date^3.12.4,ai^7.0.93playgrounds/vuevue-router^5.3.1Six upstream names are absent here (
@ai-sdk/anthropic,@ai-sdk/gateway,@iconify-json/lucide,@takumi-rs/core,nuxt-agent-discovery), and the@internationalized/*peer ranges are^3.0.0on both sides — untouched by upstream too.Two upstream changes are n/a: the
zodentry added toplaygrounds/nuxt/nuxt.config.ts'spaths(that config has notypescriptblock at all here), and theContentTocsnapshot, which moves only under happy-dom 20.14 — a version we do not take.playgrounds/demo, ours aloneDeclares four of the bumped packages. Two sat at upstream's pre-image and take the bump mechanically. The other two had drifted behind this fork's own root:
@ai-sdk/vue^4.0.77against our^4.0.85,ai^7.0.77against^7.0.85. Brought up with the rest — this is exactly the "one-time divergence becomes permanent" failuredep-parity.json's note describes, and demo is invisible to that file because upstream has no counterpart.maskaand@internationalized/datein the nuxt and vue playgrounds stay put: upstream does not declare them there, so there is no pre-image to move from. Structural, not drift.happy-domis not taken, and the finding outlives this commitUpstream goes
^20.12.0→^20.14.0. Taking it turns 1450 tests and 136 snapshots red across 64 files:Vue's
markRawagainst a happy-dom proxy, raised from reka'sPresencewatcher — it reaches nearly everything that renders a collapsible.Isolated rather than guessed: with every other bump in this commit applied and happy-dom alone moved back, the suite is green. Then bisected:
The declared range was
^20.12.0, which admits every one of those. It worked only because the lockfile happened to hold 20.12.0 — any fresh resolution, a Dependabot bump or a lockfile refresh, would have taken 20.14.0 and reddened the suite with no source change to point at.~20.12.0is not enough either, since 20.12.1 already breaks.So the declaration becomes an exact pin, and the reason goes in
dep-parity.json'sexceptionswhere the nextchore(deps)port will read it. This closes a landmine rather than adding a restriction.Upstream ships
^20.14.0and is presumably green, so whatever differs is on our side — reka's version or the vitest environment. Finding it is not something a dependency-bump port can do; recorded for a follow-up.Verification
Resolved versions read from
pnpm-lock.yaml, notnode_modules— the store keeps directories from earlier installs and has previously reported a package the lockfile did not contain.Local gate green:
lint·typecheck·build(3.87 MB) ·test(347 files, 7865 passed, 6 skipped) ·test:module·repl:build.🤖 Generated with Claude Code
https://claude.ai/code/session_01JS8ypVfQSFzYVZzkTHhURb
Generated by Claude Code