chore(deps): update all non-major dependencies (js/ts) j:kit-282

[renovate-coveo]

ℹ️ Note

This PR body was truncated due to platform limits.

This PR contains the following updates:

Package	Change	Age	Adoption	Passing	Confidence
@coveo/relay-event-types	19.13.0 → 19.22.0
@playwright/mcp (source)	0.0.75 → 0.0.76
@reduxjs/toolkit (source)	2.11.2 → 2.12.0
@vitejs/plugin-react (source)	6.0.2 → 6.0.3
esbuild	0.28.0 → 0.28.1
pnpm (source)	10.33.4 → 10.34.4
prettier (source)	3.8.3 → 3.8.4
vite (source)	8.0.14 → 8.1.0

---

Release Notes

coveo/analytics_schema (@​coveo/relay-event-types)

v19.22.0

Compare Source

v19.21.0

Compare Source

v19.19.1

Compare Source

v19.19.0

Compare Source

v19.18.0

Compare Source

v19.17.0

Compare Source

v19.16.0

Compare Source

v19.15.0

Compare Source

v19.14.0

Compare Source

microsoft/playwright-mcp (@​playwright/mcp)

v0.0.76

Compare Source

What's New

New Tools

• browser_video_show_actions / browser_video_hide_actions — Overlay action annotations on the recorded video, or hide them again (#​40914)

Tool Improvements

• Remote endpoint — remoteEndpoint now accepts a ConnectOptions object, not just a URL string (#​40964)
• --output-max-size — Cap the size of tool responses, with post-response disk eviction of oversized output (#​41031)
• --browser — Support moz-firefox BiDi channels (#​41126)

Bug Fixes

• Support remoteHeaders for the remote browser endpoint (#​40828, #​41156)
• Use waitUntil: 'commit' when navigating back/forward (#​41153)
• Report invalid tool arguments instead of failing opaquely (#​40979)
• Use a writable cache directory for MCP user data instead of the browsers path (#​40961)
• Disconnect the tracked browser when the browser tracker is disposed (#​40967)
• Report a missing ffmpeg distinctly from a missing browser (#​40867)
• Don't mark the response as closed when there are no open tabs (#​40743)
• Validate user-provided regex patterns in MCP tools (#​40752)
• Pass the time parameter to page.evaluate when waiting for a timeout (#​41037)
• Add path-traversal checks to static file serving routes (#​40715)

reduxjs/redux-toolkit (@​reduxjs/toolkit)

v2.12.0

Compare Source

This feature release adds RTK usage skills files (via TanStack Intent) exports the RTK Query hook options types for reusability, fixes issues with infinite query status flags and batching handling, and makes some small TS improvements.

Changelog

Skills Files

We've generated agent skill files that are now included in the RTK package itself in a skills folder. They cover using and migrating to modern RTK, client and server state management, and handling side effects. You can point your agent at these skills yourself, or use TanStack Intent to pick them up.

TypeScript Improvements

The types for our RTK Query hook options are now exported, which lets you stop using Parameters to extract those types for use in your own code.

The types for listener middleware matchers were tweaked to allow interface-based type guards, not just type-based definitions.

The internal IgnorePaths type was renamed to IgnoredPaths for consistency.

We now use the built-in NoInfer util that comes with TS 5.4+.

Fixes

We fixed handling of the isSuccess status flag when switching infinite query cache entries. This should prevent accidental UI flashes that were occurring due to this flag accidentally flipping.

We've added a 100ms timeout fallback to the autoBatch enhancer's requestAnimationFrame timer. We had several reports that rAF didn't work correctly when used in background tabs / opened windows, and that RTK never updated the UI. This should ensure that the updates flush correctly.

What's Changed

• Export hook options types for RTK Query hooks by @​veeceey in #​5218
• Add TanStack Intent skills for Redux Toolkit by @​phryneas in #​5249
• Keep isSuccess: true when switching infinite query cache entries by @​riqts in #​5268
• fix: allow interface-based type guards as listener matcher by @​riqts in #​5269
• fix: add setTimeout fallback to raf autoBatch strategy for background tabs by @​riqts in #​5273
• chore(toolkit): rename IgnorePaths type to IgnoredPaths by @​Ri5ha6h in #​5284
• feat(toolkit)!: switch to native NoInfer utility type by @​aryaemami59 in #​5289

Full Changelog: reduxjs/redux-toolkit@v2.11.2...v2.12.0

vitejs/vite-plugin-react (@​vitejs/plugin-react)

v6.0.3

Compare Source

evanw/esbuild (esbuild)

v0.28.1

Compare Source

• Disallow \ in local development server HTTP requests (GHSA-g7r4-m6w7-qqqr)

  This release fixes a security issue where HTTP requests to esbuild's local development server could traverse outside of the serve directory on Windows using a \ backslash character. It happened due to the use of Go's path.Clean() function, which only handles Unix-style / characters. HTTP requests with paths containing \ are no longer allowed.

  Thanks to @​dellalibera for reporting this issue.

• Add integrity checks to the Deno API (GHSA-gv7w-rqvm-qjhr)

  The previous release of esbuild added integrity checks to esbuild's npm install script. This release also adds integrity checks to esbuild's Deno install script. Now esbuild's Deno API will also fail with an error if the downloaded esbuild binary contains something other than the expected content.

  Note that esbuild's Deno API installs from registry.npmjs.org by default, but allows the NPM_CONFIG_REGISTRY environment variable to override this with a custom package registry. This change means that the esbuild executable served by NPM_CONFIG_REGISTRY must now match the expected content.

  Thanks to @​sondt99 for reporting this issue.

• Avoid inlining using and await using declarations (#​4482)

  Previously esbuild's minifier sometimes incorrectly inlined using and await using declarations into subsequent uses of that declaration, which then fails to dispose of the resource correctly. This bug happened because inlining was done for let and const declarations by avoiding doing it for var declarations, which no longer worked when more declaration types were added. Here's an example:

  // Original code
  {
    using x = new Resource()
    x.activate()
  }
  
  // Old output (with --minify)
  new Resource().activate();
  
  // New output (with --minify)
  {using e=new Resource;e.activate()}

• Fix module evaluation when an error is thrown (#​4461, #​4467)

  If an error is thrown during module evaluation, esbuild previously didn't preserve the state of the module for subsequent module references. This was observable if import() or require() is used to import a module multiple times. The thrown error is supposed to be thrown by every call to import() or require(), not just the first. With this release, esbuild will now throw the same error every time you call import() or require() on a module that throws during its evaluation.

• Fix some edge cases around the new operator (#​4477)

  Previously esbuild incorrectly printed certain edge cases involving complex expressions inside the target of a new expression (specifically an optional chain and/or a tagged template literal). The generated code for the new target was not correctly wrapped with parentheses, and either contained a syntax error or had different semantics. These edge cases have been fixed so that they now correctly wrap the new target in parentheses. Here is an example of some affected code:

  // Original code
  new (foo()`bar`)()
  new (foo()?.bar)()
  
  // Old output
  new foo()`bar`();
  new (foo())?.bar();
  
  // New output
  new (foo())`bar`();
  new (foo()?.bar)();

• Fix renaming of nested var declarations (#​4471)

  This release fixes a bug where var declarations in nested scopes that are hoisted up to module scope were not correctly being renamed during bundling. That could previously lead to name collisions when minification was disabled, which could potentially cause a behavior change. The bug has been fixed so that these hoisted declarations are now considered to be module-level symbols during the name collision avoidance pass.

• Emit var instead of const for certain TypeScript-only constructs for ES5 (#​4448)

  While esbuild doesn't generally support converting const to var for ES5 due to nested scoping rules (which is currently a build-time error), esbuild previously incorrectly converted TypeScript-only import assignment constructs into a const declaration even when targeting ES5. With this release, esbuild will now use var for this case instead:

  // Original code
  import x = require('y')
  
  // Old output (with --target=es5)
  const x = require("y");
  
  // New output (with --target=es5)
  var x = require("y");

pnpm/pnpm (pnpm)

v10.34.4: pnpm 10.34.4

Compare Source

Patch Changes

• 352ae48: Security: validate config dependency names and versions before using them to build filesystem paths. A pnpm-workspace.yaml with a traversal-shaped configDependencies name (such as ../../PWNED) or version (such as ../../../PWNED) could previously cause pnpm install to create symlinks or write package files outside node_modules/.pnpm-config and the store. Names must now be valid npm package names and versions must be exact semver versions. See GHSA-qrv3-253h-g69c.

• 352ae48: Reject path-traversal and reserved dependency aliases (such as ../../../escape, .bin, .pnpm, or node_modules) that come from a lockfile rather than a freshly resolved manifest. A crafted lockfile alias could otherwise be joined directly under a hoisted node_modules directory, letting package files be written outside the intended install root or overwrite pnpm-owned layout.

  The nodeLinker: hoisted graph builder now validates each alias at the directory sink (safeJoinModulesDir), matching the validation pnpm already performs when resolving aliases from manifests. See GHSA-fr4h-3cph-29xv.

• 352ae48: Prevent pnpm patch-remove from removing files outside the configured patches directory.

• 217fbe0: Hardened the warning printed when a project .npmrc uses environment variables in registry/auth settings: the suggested pnpm config set command is now only included for keys made up of shell-inert characters. Because the key comes from a repository-controlled .npmrc and a shell expands $(...), backticks, and $VAR even inside double quotes, a crafted key could otherwise have turned the suggested copy-paste command into command execution.

Platinum Sponsors

Gold Sponsors

v10.34.3: pnpm 10.34.3

Compare Source

⚠️ Security fix — environment variables in a project .npmrc (action may be required)

Following GHSA-3qhv-2rgh-x77r, pnpm no longer expands ${ENV_VAR} placeholders that come from a repository-controlled config file, because a malicious repository could otherwise use them to leak your environment secrets (npm tokens, CI job tokens, etc.) to an attacker-controlled registry during install. This applies to:

• the project/workspace .npmrc — registry, @scope:registry, proxy URLs, URL-scoped keys (//host/…), and credential values (_authToken, _auth, _password, username, tokenHelper, cert, key);
• registry URLs in pnpm-workspace.yaml.

This release also closes a bypass where a project .npmrc could set userconfig, globalconfig, or prefix to make pnpm load a repo-supplied file as trusted config (via @pnpm/npm-conf@3.0.3).

Environment variables are still expanded in trusted config: your user-level ~/.npmrc, the global config, CLI options, and environment config.

If your authentication broke after upgrading, move the token out of the committed .npmrc:

# Writes to your user/global config, not the repository:
pnpm config set "//registry.npmjs.org/:_authToken" "$NPM_TOKEN"

Or keep the ${NPM_TOKEN} line but put it in your user-level ~/.npmrc instead of the repo. In GitHub Actions, actions/setup-node with registry-url already writes a user-level .npmrc, so NODE_AUTH_TOKEN keeps working. For other CI where editing each pipeline is hard, set NPM_CONFIG_USERCONFIG=.npmrc in the CI environment to declare the project .npmrc trusted.

See https://pnpm.io/npmrc for full migration details.

Patch Changes

• Improved the warning printed when a project .npmrc uses an environment variable in a registry/proxy URL or in registry credentials. The message now explains why the setting was ignored and how to migrate it to a trusted source — for example by running pnpm config set "<key>" <value> to store it in the global config, or by keeping the ${...} line in the user-level ~/.npmrc — with a link to https://pnpm.io/npmrc.
• A repository-controlled project or workspace .npmrc can no longer redirect which files pnpm loads as its trusted user and global configuration. Previously such a file could set userconfig, globalconfig, or prefix to point at an attacker-supplied file shipped in the repository, and pnpm would load it as a trusted config source — bypassing the protection that prevents repository config from expanding environment variables into registry request destinations and credentials, and allowing it to set tokenHelper. The user/global config file locations are now resolved only from trusted sources (CLI options, environment config, the npm builtin config, and defaults) before the project and workspace .npmrc files are read. Fixed by upgrading @pnpm/npm-conf to 3.0.3.

Platinum Sponsors

Gold Sponsors

v10.34.2: pnpm 10.34.2

Compare Source

⚠️ Security fix — environment variables in a project .npmrc (action may be required)

Following GHSA-3qhv-2rgh-x77r, pnpm no longer expands ${ENV_VAR} placeholders that come from a repository-controlled config file, because a malicious repository could otherwise use them to leak your environment secrets (npm tokens, CI job tokens, etc.) to an attacker-controlled registry during install. This applies to:

• the project/workspace .npmrc — registry, @scope:registry, proxy URLs, URL-scoped keys (//host/…), and credential values (_authToken, _auth, _password, username, tokenHelper, cert, key);
• registry URLs in pnpm-workspace.yaml.

This release also closes a bypass where a project .npmrc could set userconfig, globalconfig, or prefix to make pnpm load a repo-supplied file as trusted config (via @pnpm/npm-conf@3.0.3).

Environment variables are still expanded in trusted config: your user-level ~/.npmrc, the global config, CLI options, and environment config.

If your authentication broke after upgrading, move the token out of the committed .npmrc:

# Writes to your user/global config, not the repository:
pnpm config set "//registry.npmjs.org/:_authToken" "$NPM_TOKEN"

Or keep the ${NPM_TOKEN} line but put it in your user-level ~/.npmrc instead of the repo. In GitHub Actions, actions/setup-node with registry-url already writes a user-level .npmrc, so NODE_AUTH_TOKEN keeps working. For other CI where editing each pipeline is hard, set NPM_CONFIG_USERCONFIG=.npmrc in the CI environment to declare the project .npmrc trusted.

See https://pnpm.io/npmrc for full migration details.

Patch Changes

• Package-manager bootstrap traffic is now resolved through trusted registries and trusted network config. When pnpm downloads the pnpm version requested by a repository's packageManager field, the registry it fetches from (and the proxy/TLS settings used for that traffic) now come exclusively from trusted config sources — CLI options, env config, user and global .npmrc — defaulting to the public npm registry, instead of the repository's project/workspace settings.
• pnpm now verifies the npm registry signature of a package-manager binary before spawning it. When the packageManager field (or pnpm self-update) makes pnpm download another pnpm version, the staged install is verified corepack-style: the integrity recorded in the staged lockfile must carry a valid npm registry signature for the exact name@version, validated against npm's public signing keys that ship embedded in the pnpm CLI. Verification fails closed — a tampered download, an unsigned package, or an unreachable registry refuses the version switch rather than running an unverified binary. It runs only when the wanted version is actually downloaded (a tools-directory cache miss), so repeated commands pay no extra network round trip.
• Environment variable expansion is now trust-aware for registry/auth config and request destinations. Repository-controlled config files (the project and workspace .npmrc and pnpm-workspace.yaml) can no longer expand ${...} placeholders in registry/proxy request destinations, URL-scoped keys, or registry credential values, preventing repository-controlled configuration from exfiltrating environment secrets through request URLs. Trusted user/global/CLI/env config keeps full env expansion, so existing token and registry setup flows continue to work.
• Reject reserved manifest bin names ("", ".", "..", and scoped forms such as @scope/..) when resolving a package's bins. These names previously passed the bin-name guard and, when joined to the global bin directory during global remove/update/add operations, could resolve to the global bin directory itself or its parent and have it recursively deleted.
• Require trusted package identity before package-name onlyBuiltDependencies (and allowBuilds) entries can approve lifecycle scripts for git, git-hosted tarball, direct tarball, and local directory artifacts. To approve one of those artifacts explicitly, use its peer-suffix-free lockfile depPath as the key. Lockfile entries are now rejected when a registry-style dependency path (name@semver) is backed by a git, directory, or git-hosted tarball resolution (ERR_PNPM_RESOLUTION_SHAPE_MISMATCH), so the dependency path is a reliable artifact identity by the time scripts can run.
• pnpm now verifies the detached OpenPGP signature of a Node.js release's SHASUMS256.txt against the Node.js release team's public keys (embedded in the pnpm CLI) before trusting its hashes. The Node.js download mirror is repository-configurable (node-mirror:<channel> in .npmrc), and the integrity check previously trusted a SHASUMS256.txt fetched from that same mirror — a circular check that a malicious mirror could satisfy with a tampered binary and matching hashes. A mirror that proxies the real signed SHASUMS keeps working unchanged. Only the release channel publishes signed SHASUMS files, so pre-release channels (rc, nightly, …) remain unverified.

Platinum Sponsors

Gold Sponsors

v10.34.1: pnpm 10.34.1

Compare Source

Patch Changes

• Reject pnpm-lock.yaml entries whose remote tarball resolution: block is missing the integrity field. Previously the worker that extracts a downloaded tarball skipped hash verification when no integrity was supplied and minted a fresh one from the unverified bytes, so an attacker who could both alter the lockfile (e.g. via a pull request that strips integrity:) and serve modified content at the referenced tarball URL could install a tampered package without any error — including under --frozen-lockfile. pnpm now fails closed at lockfile-read time with ERR_PNPM_MISSING_TARBALL_INTEGRITY. Git-hosted tarballs (gitHosted: true or a URL on codeload.github.com / bitbucket.org / gitlab.com) and file: tarballs are exempt — the commit SHA in a git-host URL and the user-controlled local path already anchor the bytes.

Platinum Sponsors

Gold Sponsors

v10.34.0: pnpm 10.34

Compare Source

Minor Changes

• Treat tarball-integrity mismatches against the lockfile as a hard failure by default. Previously, pnpm install (non-frozen) would log ERR_PNPM_TARBALL_INTEGRITY, silently re-resolve from the registry, and overwrite the locked integrity — which meant a compromised registry, proxy, or republished version could substitute attacker-controlled content on a clean machine even though the project shipped a committed lockfile.

  pnpm install now exits with ERR_PNPM_TARBALL_INTEGRITY and a hint pointing at the new opt-in flag.

  The only opt-in is pnpm install --update-checksums — narrowly scoped to refreshing the locked integrity values from what the registry currently serves. Mirrors yarn's flag of the same name. A warning still prints when the bypass takes effect so the operation is auditable.

  --force and pnpm update deliberately do not bypass the integrity check. They are routine refresh operations; silently overwriting a locked integrity in those flows would erase the protection a committed lockfile is supposed to provide. --frozen-lockfile behavior is unchanged. --fix-lockfile keeps its documented purpose (filling in missing lockfile entries) and is also not a bypass.

Patch Changes

• Pin unscoped per-registry settings (_authToken, _auth, username/_password, tokenHelper, inline cert/key) to the registry declared in the same config source at load time, so a later layer overriding registry= (workspace .npmrc, pnpm-workspace.yaml, CLI --registry) cannot redirect a credential or client certificate authored for a different host. A deprecation warning is emitted whenever an unscoped per-registry setting is encountered, naming the source and the URL it was pinned to. Reported by JUNYI LIU.
• Fixed minimumReleaseAge handling when cached metadata is abbreviated. The npm registry returns abbreviated package metadata (without the per-version time field) by default, which made the maturity check throw ERR_PNPM_MISSING_TIME whenever cached abbreviated metadata was reused. pnpm now upgrades cached abbreviated metadata to the full document via a follow-up fetch when minimumReleaseAge is active, persists the upgrade to the on-disk cache so subsequent installs skip the extra fetch, and lets ERR_PNPM_MISSING_TIME from the cache fast-path fall through to the network fetch even under strict mode.
• Reject git resolutions whose commit field is not a 40-character hexadecimal SHA before invoking git. A malicious lockfile could otherwise smuggle a value such as --upload-pack=<command> through git fetch / git checkout, which on SSH or local-file transports executes the supplied command.
• Reject patch files whose diff --git headers reference paths outside the patched package directory. Previously a malicious .patch file added via a pull request could write, delete, or rename arbitrary files reachable by the user running pnpm install.
• Fixed --prefix=<dir> not being honored when locating the workspace root. The --prefix → dir rename was applied after workspace detection, so workspace settings declared in <dir>/pnpm-workspace.yaml were not loaded when pnpm was invoked from outside <dir> #​11535.
• Reject dependency aliases that contain path-traversal segments (such as @x/../../../../../.git/hooks) when reading them from a package manifest or symlinking them into node_modules. A malicious registry package could otherwise use a transitive dependency key to make pnpm install create symlinks at attacker-chosen paths outside the intended node_modules directory.

Platinum Sponsors

Gold Sponsors

	✂ Note PR body was truncated to here. Configuration 📅 Schedule: (in timezone America/Toronto) Branch creation "before 6:00am on Tuesday" Automerge "after 9:00am and before 12:00pm on tuesday, wednesday, thursday" 🚦 Automerge: Disabled by config. Please merge this manually once you are satisfied. ♻ Rebasing: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox. 👻 Immortal: This PR will be recreated if closed unmerged. Get config help if that's undesired. If you want to rebase/retry this PR, check this box This PR has been generated by Mend Renovate.

[Copilot]

Copilot can't review bot-authored pull requests automatically. A user with Copilot access can request a review manually.

[changeset-bot]

⚠️ No Changeset found

Latest commit: bb01240

Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.

This PR includes no changesets

When changesets are added to this PR, you'll see the packages that this PR includes changesets for and the associated semver types

Click here to learn what changesets are, and how to add one.

Click here if you're a maintainer who wants to add a changeset to this PR

[svcsnykcoveo]

✅ Snyk checks have passed. No issues have been found so far.

Status	Scan Engine	Critical	High	Medium	Low	Total (0)
✅	Open Source Security	0	0	0	0	0 issues
✅	Licenses	0	0	0	0	0 issues
✅	Code Security	0	0	0	0	0 issues

💻 Catch issues earlier using the plugins for VS Code, JetBrains IDEs, Visual Studio, and Eclipse.

[chromatic-com]

Important

Testing in progress…

🟢 UI Tests: 458 tests unchanged
⏳ UI Review: Comparing 458 stories…
Storybook Publish: 458 stories published

[chromatic-com]

Tip

All tests passed and all changes approved!

🟢 UI Tests: 458 tests unchanged
🟢 UI Review: 458 stories published -- no changes
Storybook Publish: 458 stories published

[pkg-pr-new]

• @coveo/pkg-new-template

@coveo/atomic

npm i https://pkg.pr.new/@coveo/atomic@7904

@coveo/atomic-hosted-page

npm i https://pkg.pr.new/@coveo/atomic-hosted-page@7904

@coveo/atomic-legacy

npm i https://pkg.pr.new/@coveo/atomic-legacy@7904

@coveo/atomic-react

npm i https://pkg.pr.new/@coveo/atomic-react@7904

@coveo/auth

npm i https://pkg.pr.new/@coveo/auth@7904

@coveo/bueno

npm i https://pkg.pr.new/@coveo/bueno@7904

@coveo/create-atomic

npm i https://pkg.pr.new/@coveo/create-atomic@7904

@coveo/create-atomic-component

npm i https://pkg.pr.new/@coveo/create-atomic-component@7904

@coveo/create-atomic-component-project

npm i https://pkg.pr.new/@coveo/create-atomic-component-project@7904

@coveo/create-atomic-result-component

npm i https://pkg.pr.new/@coveo/create-atomic-result-component@7904

@coveo/create-atomic-rollup-plugin

npm i https://pkg.pr.new/@coveo/create-atomic-rollup-plugin@7904

@coveo/headless

npm i https://pkg.pr.new/@coveo/headless@7904

@coveo/headless-react

npm i https://pkg.pr.new/@coveo/headless-react@7904

@coveo/shopify

npm i https://pkg.pr.new/@coveo/shopify@7904

commit: bb01240

[github-actions]

🔗 Scratch Orgs ready to test this PR:

• ✅ LWS Enabled: Open Org
• ✅ LWS Disabled: Open Org

[alexprudhomme]

Held vite back at 8.0.14 in this group update. vite@8.1.0 (rolldown-based) miscompiles the Atomic Storybook bundle: MSW's top-level checkGlobals() call survives in the _base/mock chunks while its function declaration is dropped, producing ReferenceError: checkGlobals is not defined at story load. This broke both Run Chromatic visual tests on Atomic (Failed to extract stories) and CDN Checks (Atomic components never bootstrap → element(s) not found).

Reproduced locally: build:storybook with vite@8.1.0 emits a dangling checkGlobals() call with no definition; reverting to 8.0.14 resolves it. The other bumps in this group (relay-event-types, playwright/mcp, redux-toolkit, plugin-react, esbuild, prettier, pnpm) are unaffected and kept. vite 8.1.0 can be retried separately once the rolldown regression is fixed upstream.

[alexprudhomme]

Upstream issue tracking this regression: rolldown/rolldown#10048 — "Rolldown emits __commonJS helper call sites without the definition (vite 8.1.x Storybook build → __commonJS is not defined)". Same root cause and context as ours (Storybook build under vite 8.1.x / rolldown 1.1.2 emits a call site without hoisting/importing its definition into the consuming chunk); our symbol just happens to be MSW's checkGlobals instead of __commonJS. Related dropped-binding regressions: rolldown/rolldown#9961, #9964, #9806. Upstream workaround is the same as applied here — pin vite to 8.0.x.