Skip to content

Upgrade @vue/reactivity from ~3.1.1 to ~3.5.40#4861

Open
oddvalue wants to merge 1 commit into
alpinejs:mainfrom
oddvalue:upgrade/vue-reactivity-3.5
Open

Upgrade @vue/reactivity from ~3.1.1 to ~3.5.40#4861
oddvalue wants to merge 1 commit into
alpinejs:mainfrom
oddvalue:upgrade/vue-reactivity-3.5

Conversation

@oddvalue

Copy link
Copy Markdown

What

Bumps @vue/reactivity in the alpinejs and csp packages from the ~3.1.1 line
(2021) to ~3.5.40, and adapts the reactivity engine registration to the modern
effect API.

How

The registration in packages/alpinejs/src/index.js (and the csp build) now closes
over the runner returned by effect() and hands it to Alpine's scheduler itself:

effect: (callback, options = {}) => {
    let runner = effect(callback, {
        scheduler: () => {
            if (! runner) return

            options.scheduler ? options.scheduler(runner) : runner()
        },
    })

    return runner
},

The runner is the same object Alpine stores in el._x_effects, preserving the
identity that the scheduler queue dedupe and dequeueJob (mutation.js) rely on.

Note: the mergeProxies setter workaround in scope.js is still required — the
target === toRaw(receiver) guard in @vue/reactivity's set trap is unchanged
through 3.6.

Backward compatibility

No public API or behavior changes. setReactivityEngine consumers are unaffected —
the adapter satisfies Alpine's existing engine contract. Full Cypress suite
(569 tests) and Vitest suite (172 tests) pass identically before and after.

Performance

Two harnesses, run against identical Alpine source with only the @vue/reactivity
version changed. Medians across repeated runs; deltas are relative to 3.1.5.
(3.6.0-rc.1 columns included for context on the follow-up bump below.)

Reactivity layer only (Node, Alpine's effect/scheduler usage pattern):

Scenario 3.1.5 3.5.40 Δ 3.5 3.6.0-rc.1 Δ 3.6
create 50k effects 126ms 152ms +21%* 81ms −36%
1k effects × 100 triggers 58ms 54ms −7% 45ms −22%
array-iteration effects 286ms 149ms −48% 117ms −59%
deep JSON.stringify watch 134ms 140ms +4%* 115ms −14%

* within run-to-run noise (±20%); the array-tracking win is consistent across
every run and is the headline — it's the x-for hot path (Vue 3.4/3.5 rewrote
array instrumentation).

End-to-end in headless Chrome (js-framework-benchmark-style x-for table):

Op 3.1.5 3.5.40 Δ 3.5 3.6.0-rc.1 Δ 3.6
create 10k rows 1338ms 1232ms −8% 1195ms −11%
append 1k to 1k 154ms 125ms −19% 144ms −6%
update every 10th of 10k 184ms 173ms −6% 165ms −10%
clear 10k 253ms 210ms −17% 214ms −15%
init 2000 components 210ms 186ms −11% 200ms −5%

End-to-end, 3.5.40 already lands in the same range as the 3.6 RC — DOM work
dominates, so most of the user-visible win ships with this PR. Memory at
Alpine-typical scale is unchanged across all three versions.

Follow-up

Vue 3.6 (the alien-signals reactivity rewrite, currently at 3.6.0-rc.1) keeps the
same contract — verified against the RC with the full suite green. Once 3.6 stable
tags, upgrading becomes a one-line version bump and picks up the remaining
reactivity-layer headroom in the tables above.

Since Vue 3.2, the effect scheduler option is invoked with no arguments
(in 3.1 it received the effect job), which is what has kept Alpine
pinned to the 3.1 line. This adapts the reactivity engine registration
in both the alpinejs and csp packages: the effect wrapper closes over
the runner returned by @vue/reactivity and hands it to Alpine's
scheduler itself. The runner is the same object Alpine stores in
el._x_effects, preserving the identity that the scheduler queue
(queue.includes) and dequeueJob rely on.

The mergeProxies setter workaround in scope.js is still required: the
"target === toRaw(receiver)" guard in @vue/reactivity's set trap is
unchanged through 3.6.

No public API or behavior changes. Full Cypress suite (569 tests) and
Vitest suite (172 tests) pass identically before and after the bump.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
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