Skip to content

fix(init): match the React starter's oxc-transform-react to @vitejs/plugin-react - #637

Merged
cpojer merged 1 commit into
voidzero-dev:mainfrom
honbin:fix/react-scaffold-oxc-version
Oct 29, 2026
Merged

cpojer merged 1 commit into
voidzero-dev:mainfrom
honbin:fix/react-scaffold-oxc-version

Conversation

@honbin

@honbin honbin commented Oct 29, 2026 •

Copy link
Copy Markdown
Contributor

What

Updates the React starter's oxc-transform-react from ^0.149.0 to ^0.152.0, and adds a unit test (template.test.ts) that compares it with the optional peer range declared by the installed @vitejs/plugin-react.

Why

The React starter enables react({ compiler: true }). @vitejs/plugin-react 6.1.2, which @void/react depends on, declares oxc-transform-react: ^0.152.0 as an optional peer. On 0.x that range is 0.152.x only, so new projects started with an invalid peer (npm ls reports it, and strict peer installs can fail).

The pinned range already differed from the peer when it was introduced (@vitejs/plugin-react 6.1.1 declared ^0.145.0), and nothing caught it. The new test fails when a catalog bump moves the peer, so the starter has to be updated in the same change.

Verification

  • template.test.ts passes, and reverting the range to ^0.149.0 makes it fail with expected '^0.149.0' to be '^0.152.0'.
  • vp run --filter ./packages/void typecheck passes.
  • Built an existing Void 1.3.0 React project with the same voidReact({ react: { compiler: true } }) setup and oxc-transform-react@0.152.0 installed: npm ls no longer reports the invalid peer, the build passes, and the SSR bundle matches the 0.149.0 build apart from the project path and deployment ID.

🤖 Generated with Claude Code

…lugin-react

The React starter enables `react({ compiler: true })` and adds
oxc-transform-react ^0.149.0, but @vitejs/plugin-react 6.1.2, which
@void/react depends on, declares an optional peer of ^0.152.0. On 0.x
that range is 0.152.x only, so new projects start with an invalid peer
(`npm ls` reports it, and strict peer installs can fail).

The range had drifted unnoticed since it was added, so a unit test now
compares it with the installed plugin's peer and fails when a catalog
bump moves it.
@cpojer
cpojer self-requested a review October 29, 2026 13:04

@cpojer cpojer left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This makes sense, although it should probably just be part of the deps setup so it automatically gets updated when we update real deps for Void.

@cpojer
cpojer merged commit d09e80e into voidzero-dev:main Oct 29, 2026
2 checks passed
@honbin
honbin deleted the fix/react-scaffold-oxc-version branch October 29, 2026 13:13
@honbin

honbin commented Oct 29, 2026

Copy link
Copy Markdown
Contributor Author

Thanks for merging! Agreed it would be better if this followed the real deps automatically.

One thing to keep in mind if we do that: the range has to follow @vitejs/plugin-react's optional peer, not oxc-transform-react's own latest. If it were a regular catalog dependency and deps were bumped to latest, it would move to 0.156.x while plugin-react 6.1.2 still declares ^0.152.0, and the update itself would create the invalid peer again.

So the automatic approach would probably be to generate the starter's range from the installed plugin-react's peerDependencies['oxc-transform-react'] at build time, instead of hard-coding it. Then bumping plugin-react updates the starter too. Happy to send a PR for that if you'd like, otherwise the test added here at least fails when the peer moves.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants