vite-plugin-react

Description I am a meta-framework developer that my library incorporates vite's javascript api. My library is a cli based tool, calls vite's build() function internally, and processes user files. It is supposed to be able to run regardless of whether there is a local node_module folder in the user's cwd. I encountered the following issue issue @rolldown/plugin-babel calls babel.loadOptionsAsync with { babelrc: false, configFile: false }. When there is no config file, Babel uses process.cwd() as the dirname for resolving plugins in programmatic presets — not the directory of the file being transformed. reactCompilerPreset at @vitejs/plugin-react/dist/index.js:46 returns: preset: () => ({ plugins: [["babel-plugin-react-compiler", options]] }) // ^ bare string, not a pre-resolved absolute path Babel must then locate babel-plugin-react-compiler via: import.meta.resolve("babel-plugin-react-compiler", pathToFileURL(path.join(process.cwd(), "babel-virtual-resolve-base.js")).href) When process.cwd() is a directory that doesn't have babel-plugin-react-compiler in its node_modules ancestry — e.g., / (the Docker container default) — the resolution fails. It needs to ensure Babel receive an absolute path, so it never needs to do CWD-relative resolution

Describe the bug :robot: AI Disclosure: Claude Code has written up majority of this issue and most of the reproduction README. I, as a human, still take responsibility for it. Summary When two entries resolve to the same module (e.g. and , where can be any package that peer-depends on ), the optimizer emits two chunks for it — one holds the real module, the other re-exports it. Which one is "canonical" vs. the re-export is not stable across optimizer passes: a re-optimization can swap them. If that re-optimization is triggered after some modules have already been served (a dependency discovered at request time), a consumer loaded before the swap and one loaded after end up bound to two different real instances of the module. For React this is / ; the page then auto-reloads () and the error vanishes — so it's cold-start-only, first-render-only. Detailed explanation can be found in the reproduction repository's README. Context I've been developing a React framework based on @vitejs/plugin-rsc. This issue originally surfaced as a framework bug, but a thorough investigation made us believe that this is a Vite issue. The repro still uses because it is the way we are aware of for reliably reproducing the issue, but we believe this issue is in Vite's Deps Optimization, hence a bug report in this repo. The trigger path (via ): a package imported by a server component is reached on the browser through a request-time module that the optimizer's initial scan can't follow — so the package (and the React it imports) is discovered on the first render and forces the re-optimization. Side Note: possible another form of this bug Initially this bug surfaced as a different error like this: a severer ES Modules link time error. This version of error is not included in this bug report because (1) we couldn't reproduce this without involving our framework and (2) we are not sure whether they are truly same origin. Read more about this at https://github.com/uhyo/funstack-static/issues/124 and https://github.com/uhyo/funstack-static/issues/128. Reproduction https://github.com/uhyo/vite-rsc-deps-issue-repro/tree/repro/duplicate-react-cold-start Steps to reproduce System Info Used Package Manager pnpm Logs _No response_ Validations [x] Follow our Code of Conduct [x] Read the Contributing Guidelines. [x] Read the docs. [x] Check that there isn't already an issue that reports the same bug to avoid creating a duplicate. [x] Make sure this is a Vite issue and not a framework-specific issue. For example, if it's a Vue SFC related bug, it should likely be reported to vuejs/core instead. [x] Check that this is a concrete bug. For Q&A open a GitHub Discussion or join our Discord Chat Server. [x] The provided reproduction is a minimal reproducible example of the bug.

Extracted from #1246. Inline transforms currently produce invalid output for object methods and static class methods because method syntax cannot be replaced like a standalone function expression. This rewrites supported methods to property/field assignments and gives their hoists method-derived names. Tests cover identifier and computed object/static methods, plus explicit errors for instance, private, getter, and setter methods.