Fix/1422 swc jsx development

[whydidoo]

Part of #1422.

Summary

getSwcLoaderOptions (used by getJsTransformRules) set jsc.transform.react.development from the JSX runtime instead of the build mode. As a result:

• dev builds on the default automatic runtime emitted jsx instead of jsxDEV, so they had no __source/__self, accurate component stacks or "open in editor";
• classic production builds kept the dev transforms.

 getSwcLoaderOptions
-  react.development = jsxRuntime === 'classic'
+  react.development = options.development   # only when passed explicitly
 RepackPlugin.apply
+  builtin:swc-loader rules (incl. oneOf / nested rules) without explicit `development`
+    → development = mode === 'development'

• New development option on getSwcLoaderOptions and getJsTransformRules({ swc: { development } }).
• Dev builds now import <importSource>/jsx-dev-runtime. If a custom importSource doesn't ship it, set swc: { development: false }.

Test plan

• tests/integration/src/plugins/RepackPlugin.test.ts (Rspack): with getJsTransformRules() + RepackPlugin, development mode gives true, production gives false, and an explicit development: false is kept. These were red before the change.

[changeset-bot]

🦋 Changeset detected

Latest commit: a7a6386

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 6 packages

Name	Type
@callstack/repack	Patch
@callstack/repack-plugin-expo-modules	Patch
@callstack/repack-plugin-nativewind	Patch
@callstack/repack-plugin-reanimated	Patch
@callstack/repack-dev-server	Patch
@callstack/repack-init	Patch

Not sure what this means? Click here to learn what changesets are.

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

[vercel]

@whydidoo is attempting to deploy a commit to the Callstack Team on Vercel.

A member of the Team first needs to authorize it.

[dannyhw]

Thanks for picking this up. The bug is real, and the getSwcLoaderOptions change fixes it. I checked tester-app with its app code routed through getJsTransformRules: on main a dev bundle has 0 app fileName entries (no jsxDEV source info). With this PR it has 78. Prod has 0 in both.

My main concern is that the RepackPlugin walker (setSwcJsxDevelopment) turns out to be unnecessary. Rspack's builtin:swc-loader already fills in jsc.transform.react.development from mode when it's unset and jsc.transform exists. An explicit value is kept, because the merge only fills unset fields.

• Docs (https://rspack.rs/guide/features/builtin-swc-loader#jsctransformreact): "jsc.transform.react.development is automatically set based on Rspack's mode unless explicitly specified."
• Source: rspack_loader_swc/src/lib.rs on main, also present at v1.0.0.

I checked this on Rspack 1.0.0, 1.1.0, 1.3.0, 1.6.0 and 2.2.9, leaving development unset:

• Dev: automatic gives jsxDEV + fileName, and classic gives __source.
• Prod: neither runtime gives either.
• An explicit false is kept.

I also built tester-app with only the getSwcLoaderOptions change and the walker removed. The output matches the full PR exactly: 78 in dev, 0 in prod.

So leaving the field unset in the helper is the whole fix. Inline suggestions:

1. Drop setSwcJsxDevelopment and the RepackPlugin hook. Sorry, I know its unit tests were only just added at review request.
2. Update the docs, JSDoc and changeset to say Rspack's builtin:swc-loader sets the default, not RepackPlugin.
3. Make the integration tests check the compiled output instead of compiler.options.

Keeping the new development override option makes sense. Patch changeset is fine. If you'd rather keep the walker as insurance for older Rspack 1.x (the 1.x docs don't mention this behaviour, though the 1.0.0 source has it), I wouldn't block on that. In that case, though, the docs should still say that Rspack does this by default.

[dannyhw]

Thanks for the quick turnaround, this looks great. I re-checked a7a63865 locally:

• The new swc-jsx-development integration tests pass (6/6 on Rspack).
• With main's jsxRuntime === 'classic' logic temporarily restored, exactly the two buggy cases fail (automatic in dev, classic in prod), so the tests catch the regression.
• The full integration suite and the repack unit tests pass, and typecheck is clean.