`reactRouter` Vite plugin doesn't accept same options as `react` plugin, how to work around?

[lusty lantern]

I'm using Lingui with React Router and Vite, and the Lingui docs specify that you should add a babel-config to the react Vite plugin like so:

react({
      babel: {
        plugins: ["macros"],
      },
    })

Furthermore, the current way to integrate React Compiler to Vite is based on the same API: https://react.dev/learn/react-compiler#usage-with-vite

This makes reactRouter plugin adoption difficult, since it doesn't offer the ability to send any args.

Is there a workaround for this issue? Or could the reactRouter-plugin even re-export the react-plugin options?

• React Router v7

[lusty lantern]

Similar question asked in Lingui discord: #974704045346394172 message

[tardy veldt]

You might find https://pnpm.io/cli/patch useful as a workaround to add the macro plugin in to the plugins.

https://github.com/remix-run/react-router/blob/70374283584e0b30ebcc60a84d1026c87ff31649/packages/react-router-dev/vite/plugin.ts#L1528

[lusty lantern]

Possibly, but I'm confused as to why the public API wouldn't support my use case, it doesn't seem very foreign. Thanks for pointing that out though!

Checking out this PR, it seems that we might be using a react-router.config.ts (undocumented?), which on the other hand only supports

  ssr?: boolean;
  basename?: string;
  prerender?: boolean | string[];
  appDirectory?: string;

so I'm not sure that will help me.

[tardy veldt]

Patching the react-router code to add a "macros" plugin should work. I agree it would be nice if there were hooks to customize such things without patching.

[lusty lantern]

So exact syntax would then be: plugins: ["macros", [require("react-refresh/babel"), { skipEnvCheck: true }]]?

I feel like this ought to be a common enough problem (React compiler for example depends on the same pattern as of today) to have a more robust solution than manually patching (and thus complicating future updates), so I'm hesitant to commit to a patch without a confirmation that this use case is intended to be unsupported.

Again though, thanks.