vite-plugin-react

Bug The first cold request to a next-intl app under returns 500 with / . The next request succeeds. The trigger is the second resolution in . The actual import resolves from inside ; the identity check resolves again from . For root-resolvable transitive dependencies, that second lookup calls Vite's , causing optimization and a reload during rendering. Here it discovers , , , and . Reproduction Application files and configuration are in the downstream report. Use its npm installation, next-intl navigation , client translation component, and locale middleware/proxy. From another terminal, without opening the app first: Expected: the first request succeeds; a package-identity check does not schedule dependency optimization. Tested package patch This is the exact patch tested against published plugin-rsc 0.5.35, with published vinext unchanged. Save as for patch-package, or apply with from the app root. The patch keeps normal import resolution and the root-identity guard, bypasses recursive probes, and tolerates only Vite's terminal version query. Build mode and explicit retain the existing path. Proposed upstream fix: give this diagnostic lookup a supported way to resolve without discovering optimized dependencies. The prototype uses the internal container option; passing it to alone does not work because Vite inherits the caller's scan state. Validation Four clean starts failed before the patch; all four succeeded after changing plugin-rsc alone. Restoring the package restored the failure. Tested Cloudflare compatibility dates: and . Eight focused resolver checks and a production build also passed; this does not establish browser-hydration or full upstream-suite compatibility. Versions: macOS arm64, Node 24.21.0, npm, Vite 8.3.1, plugin-rsc 0.5.35, Cloudflare Vite plugin 1.61.0, next-intl 4.14.7, React 19.3.0, vinext 1.0.0-beta.13. Related: #1273. This identifies a specific trigger for mid-request optimization.

Description Fixes #1448. lowers JSX in with . That transform defaults to when the option is unset. Vite's oxc transform never sees the original JSX, so the per-file tsconfig inference restored in #726 does not apply. With no plugin-level , the compiler transform now reads from the file's tsconfig using the same Vite uses for oxc JSX. An explicit option still overrides every file. Reproduction from the issue (two TSX files, no pragmas): What I chose: fill from the file's tsconfig inside the compiler plugin. Alternative: set in the compiler plugin so Vite's oxc transform keeps owning JSX, Fast Refresh, and tsconfig inference. Why:** #1419 put JSX and Fast Refresh in the compiler plugin so the compiler sees the original AST. This change only supplies the missing import source and stays reversible. Happy to switch to preserve-JSX if that is preferred. is a hidden rolldown export currently used by Vite. It is loaded through Vite's installation so this package does not gain a new runtime dependency. If you would rather have a public Vite helper, this call site is the consumer. Checklist Read the Contributing Guidelines. Check that there isn't already a PR that solves the problem the same way. Documentation already states that is inferred from tsconfig; no extra docs. Tests fail without this change and pass with it ( unit tests).

Description In a build, resolves a server reference with . Two things make an unknown id hard for a framework to handle: 1. Inherited keys resolve. The registry is a plain object, so ids that name members do not reach the not-found branch: "loads" (it calls the inherited constructor), and or throw a from . A request that only names an unknown id should always get the not-found error. 2. The not-found error is only recognizable by its message. Frameworks want to answer an unknown server function id (a probe, or a client from an older deploy) with a 404 before reading the request body, and to report real load failures of known modules as server errors. Today the only way to tell them apart is to compare the message with , after stripping the tag the same way does. This PR looks the id up with and gives the not-found error a stable . The message is unchanged, so anything matching on it keeps working. Scope: the build path only. In dev, an unknown id is rejected earlier by the plugin with its own error; I left that alone, since it already fails loudly. Happy to add the same code there if you want both paths to match. Tests: this runtime file has no unit test harness, and I could not run the e2e suite in my environment. I checked the lookup logic in isolation (known id, missing id, , , ), and we run this exact change as a local patch in our framework's CI in the meantime. If you'd like an e2e case, point me to the fixture you prefer and I'll add one. Related: #1337 and #1346 (route-aware server reference metadata). A has-reference check could come out of that work; this PR only makes the existing not-found error reliable and recognizable.