fix(deps): update starter-peer-deps by renovate[bot] · Pull Request #746 · redwoodjs/sdk

renovate · 2025-09-19T00:01:46Z

Manual Changes and Fixes

Vite Upgrade (`7.1.5` -> `7.1.6`) and Directive Scanner Failures

Problem

We have a custom directive scanner that discovers "use client" and "use server" files. To minimize user dependencies and ensure consistent behavior, this scanner relies on the esbuild binary that ships with Vite.

The upgrade to Vite 7.1.6 introduced a breaking change via its internal esbuild dependency, which was updated from ^0.23.0 to ^0.24.0. The new esbuild version changed its API behavior, making it an error to use write: false with bundle: true for multiple entry points without specifying an outdir. This caused our directive scanner to fail. A follow-up issue also occurred where the scanner failed on virtual modules provided by Vite's config.

Solution

The scanner's esbuild configuration was updated to be compatible with the new API. This involved two changes:

Adding a temporary outdir to the configuration. Since write: false is still set, no files are written to disk.
Adding a filter to ignore virtual modules (e.g., virtual:cloudflare/worker-entry) before passing entry points to esbuild.

`@cloudflare/vite-plugin` (`1.12.4` -> `1.13.3`) and Build Process Conflict

Problem

Our production build is a multi-pass process orchestrated by buildApp.mts. It first builds an intermediate worker bundle, then "links" it with an SSR bridge to produce the final single-file artifact. This process must work in harmony with the Cloudflare plugin.

The updated @cloudflare/vite-plugin now requires the main worker entry chunk to be named index. This requires a Rollup input config like { index: '...' }. However, to create a single-file worker bundle, we need inlineDynamicImports: true, and a recent Rollup update requires this option to be used with a simple string input, not an object. This created a deadlock, preventing a successful build.

Solution

The solution was to adapt our build process to cooperate with the plugin:

The manual rollupOptions for the worker build were removed from our configPlugin.mts, allowing the @cloudflare/vite-plugin to take control and generate a valid intermediate build with an index.js chunk.
The "linker" pass in buildApp.mts was updated to hook into the plugin-generated configuration. It now modifies the existing config, re-pointing the input to the intermediate index.js artifact from the first pass.

This resolves the conflict by letting the plugin manage the build while still allowing our orchestrator to perform its essential multi-pass logic.

Dev Server Directive Scan Regression

Problem

The fix for the production build involved removing the manual rollupOptions from the worker's Vite configuration, allowing the Cloudflare plugin to manage the build. This change, while correct for production, had an unintended side-effect on the development server. The dev server failed because the directive scanner, which runs on startup, no longer had an entry point. It relied on the rollupOptions that had been removed, and it was executing before the full Vite configuration for the worker environment was resolved.

Solution

The dependency on the implicit Vite configuration was removed. The runDirectivesScan function was updated to accept an explicit entries parameter. This entry point is now passed directly from the main redwoodPlugin (for the dev command) and the buildApp function (for the build command), ensuring the scanner always has the correct starting point.

CI Infrastructure Changes: Switching to Tarball-Based Testing

Problem

The investigation into the build failures revealed that the existing CI setup, which relied on workspace linking, was running tests against stale dependencies from the monorepo's node_modules. This meant the CI was not testing against the newly upgraded package versions, which hid the build and type errors.

Solution

To ensure the CI accurately validates the project against the upgraded dependencies, the test environments for both smoke tests and E2E tests were switched to use a tarball-based installation. This process involves:

Packing the SDK into a tarball.
Copying the test project (e.g., a starter or playground app) to a clean, temporary directory.
Installing dependencies in the isolated environment using the SDK tarball.

This approach guarantees that tests run in a clean environment with the correct, newly-updated dependencies, accurately simulating a real user installation. As part of this change, the redundant check-starters.yml workflow was removed, as its type-checking coverage is now handled more reliably by the playground E2E tests.

Automated changes

This PR contains the following updates:

Package	Change	Age	Confidence
@cloudflare/vite-plugin (source)	`1.12.4` -> `1.13.3`
@cloudflare/workers-types	`4.20250913.0` -> `4.20250921.0`
react (source)	`19.2.0-canary-3fb190f7-20250908` -> `19.2.0-canary-d415fd3e-20250919`
react-dom (source)	`19.2.0-canary-3fb190f7-20250908` -> `19.2.0-canary-d415fd3e-20250919`
react-server-dom-webpack (source)	`19.2.0-canary-3fb190f7-20250908` -> `19.2.0-canary-d415fd3e-20250919`
vite (source)	`7.1.5` -> `7.1.6`
wrangler (source)	`4.35.0` -> `4.38.0`