Livewire 4.x will require Alpine 3.17.2

PR #10670 is a focused dependency chore for the Livewire 4.x branch: it bumps every Alpine.js package in the repository's package.json from ^3.17.1 to ^3.17.2 — the alpinejs core package plus all ten official @alpinejs/* plugins. No PHP code, configuration, or templates change. What the PR establishes is a new minimum for the Alpine runtime that ships with Livewire 4.x, and it does so in a deliberately staged way: the version constraints are updated now, while the npm lockfile is intentionally left untouched until Alpine 3.17.2 is actually published to npm. If you are currently on v3.8.10 and planning the jump to 4.x, this PR tells you which Alpine version you'll be getting — or needing — when you get there.

What changed in this PR

The diff touches exactly one file: package.json. Eleven dependency lines were raised:

• alpinejs: ^3.17.1 → ^3.17.2
• @alpinejs/anchor, @alpinejs/collapse, @alpinejs/csp, @alpinejs/focus, @alpinejs/intersect, @alpinejs/mask, @alpinejs/morph, @alpinejs/persist, @alpinejs/resize, @alpinejs/sort: all ^3.17.1 → ^3.17.2

These are the packages whose compiled output ends up inside the JavaScript bundle Livewire distributes. Everything else in the file (@vue/reactivity, nprogress, dev tooling like vitest) is untouched, and no lockfile changes ship with the PR.

Because all of these are caret (^) ranges, fresh installs were already permitted to resolve newer 3.x patches. The point of the bump is to raise the floor: Livewire 4.x now requires at least Alpine 3.17.2, which matters most for the pre-built bundle.

Why the bundled Alpine version matters

The default way most apps consume Livewire's JavaScript is the @livewireScripts Blade directive. That injects a pre-compiled livewire.js file with Alpine (and the plugin set above) baked in — you don't install Alpine yourself, and the version you run is determined by Livewire's own npm dependencies at build time. That is exactly what this PR controls.

Raising the constraint to ^3.17.2 guarantees that the 4.x bundle contains an Alpine release that includes the upstream fixes Livewire 4.x depends on. It also documents the requirement for anyone building the package from source or resolving dependencies from scratch: an older Alpine can no longer satisfy the build.

There is a subtle benefit for custom setups too. If you bring your own Alpine build, your app's alpinejs version and Livewire's bundled copy should stay aligned. Two different Alpine runtimes on one page can produce confusing symptoms — directives initialized twice, plugins registered against the wrong runtime, or morphing behaving oddly — so a clear, published minimum in Livewire's manifest helps everyone converge on the same version.

The two-step rollout: constraints now, lockfile later

npm lockfiles pin exact resolved versions so builds are reproducible. But you cannot pin 3.17.2 before that version exists on the registry — npm install would fail to resolve it. The PR description is explicit that the lockfile stays unchanged for now and will be regenerated from the real registry in a follow-up once Alpine 3.17.2 is published, followed by the JavaScript/build verification before the branch is marked ready.

This is good dependency hygiene: the manifest declares intent immediately, while the lockfile is only updated against versions that actually exist. The practical takeaway for anyone watching the 4.x branch is that this PR, merged alone, doesn't change any published artifact yet — the bundle update lands when the lockfile does.

Upgrading from v3.8.10: what to do

Your required action depends on how you load Livewire's scripts.

If you use @livewireScripts (or import Livewire/Alpine from the vendor ESM build), there is nothing to do. When you upgrade to 4.x, the bundle — including its Alpine runtime — is updated for you. There are no PHP or config changes in this PR.

If you compile Alpine yourself (for example, with @livewireScriptConfig in your layout and alpinejs imported in your Vite build), you need to raise your own dependency floor when adopting 4.x:

npm install alpinejs@^3.17.2
npm install @alpinejs/focus@^3.17.2 @alpinejs/collapse@^3.17.2 # any plugins you register yourself

A typical entry file then looks like this:

import Alpine from 'alpinejs'
import focus from '@alpinejs/focus'

Alpine.plugin(focus)

window.Alpine = Alpine
Alpine.start()

After installing, confirm what actually resolved with:

npm ls alpinejs

If you are staying on v3.8.10 for now, nothing in this PR affects you — it targets the 4.x branch, and the 3.x series continues to ship its own pinned Alpine version.

Takeaways

• Livewire 4.x now requires Alpine ^3.17.2 (core plus all ten official plugins) in its build manifest; constraints are merged, and the lockfile follows once 3.17.2 hits npm.
• Using the bundled @livewireScripts output? You get the new Alpine automatically — no action needed.
• Building your own Alpine? Raise alpinejs and any @alpinejs/* plugins to ^3.17.2 before upgrading, and keep your version aligned with Livewire's bundle.
• No PHP, configuration, or template changes are involved.
• On v3.8.10, you're unaffected until you upgrade to 4.x.

Sources

• Pull request #10670
• Release v4.4.7