change the react refresh url from `/@refresh-runtime`

[paperclover]

Related plugins

• plugin-react

• plugin-react-swc

• plugin-react-oxc

• plugin-rsc

Description

in our application (tanstack start), there is an ssr route on /@{username} to show a user's profile, and the vite react plugin uses /@react-refresh without any trailing data. this causes the routes to conflict.

we never noticed this, because on localhost the browser sends Sec-Fetch-Dest: script, which vite uses to resolve the conflict. but in my current bug search, i am using the site from my phone in dev-mode, using the non-localhost http://169.254.x.x, which will not send these headers. the app now fails to run any client-side javascript since the script fetches "404 user not found" as HTML.

Suggested solution

• change /@refresh-runtime to something else harder to collide with
  • perhaps /node_modules/@vitejs/plugin-react/dist/refresh-runtime.js to better reflect where the file is coming from
  • changeable with a configuration (my initial thought but i think the detailed path is better

Alternative

perhaps it should be configurable in vite to add a full prefix to the specifiers.

Additional context

i have a workaround (deleting the profile page temporarily) but would love this for coworkers that may need to perform a similar type of debug.

Validations

• Follow our Code of Conduct
• Read the Contributing Guidelines.
• Read the docs.
• Check that there isn't already an issue that request the same feature to avoid creating a duplicate.

[hi-ogawa]

/@react-refresh import became a sort of unwritten public API, so we likely cannot change. Making it configurable might be option, but I also wonder whether other Vite logic might be also failing if we cannot assume Sec-Fetch-Dest: script (so that would be something Vite needs to fix?)

In the mean time, this might serve as a workaround without involving application routes change
https://stackblitz.com/edit/vitejs-vite-g9cmftzv?file=vite.config.ts

export default defineConfig({
  plugins: [
    {
      name: 'workaround',
      configureServer(server) {
        server.middlewares.use((req, res, next) => {
          if (req.url === '/@react-refresh') {
            req.url =
              '/node_modules/@vitejs/plugin-react/dist/refresh-runtime.js';
          }
          next();
        });
      },
    },
    react(),
  ],
});

[paperclover]

thanks for the middleware. when testing i realize the overwrite url depends on the workspace / node_modules layout, so i have to resolve its path. and of course, cannot view the user with that username (not a big deal)

const reactRefresh = `/@fs${path.resolve(fileURLToPath(import.meta.resolve("@vitejs/plugin-react")), "../refresh-runtime.js")}`;

/@react-refresh import became a sort of unwritten public API, so we likely cannot change

can we keep the resolver plugin behavior the same (resolve and serve /@react-refresh), but change the preamble to point directly to the file?

this means runtimePublicPath would be used for backwards compatibility only, and preambleCode and addRefreshWrapper would changed to match the actual location of the file, no longer needing a plugin to help resolve it. then preserve the backwards compatibility resolution code, which server routes would overwrite anyways. (then i guess change the readme url templating to happen here)

this solution would keep existing compatibility and fix this edge case for everyone using the vite react plugin in its normal setting.

I also wonder whether other Vite logic might be also failing if we cannot assume Sec-Fetch-Dest: script

likely, but the edge cases there are extremely extremely small. if there isn't an application route that matches the exact string, then vite will serve the js bundle. /@string with no subpaths is simply a very easy to hit name, normally its a filesystem path /src/hello.ts or /node_modules/.vite/deps/chunk-KWLDUQCZ.js or /@fs/Users/clo/dev/1/node_modules/.../index.js. but yeah, that does exist for anyone using a older browser or vite --host

a much bigger break would be allowing a config option to change the prefix for those from / to something else, but that seems like a change too big.