Does React Router 7 (framework) disallow devDependencies?

[connorjs]

I am experimenting with React Router framework for the first time. To avoid confusion for our developers, we just use devDependencies for applications because the bundler (Vite, esbuild, your-bundler) handles dependencies.

Edit: Note: Right now, we use SPA/client-side only.

However, react-router build fails citing no @react-router/node (which is in devDependencies).

Error: Could not determine server runtime. Please install @react-router/node, or provide a custom entry.server.tsx/jsx file in your app directory.

If I move @react-router/node to dependencies it works. (Although it uninstalls all of my devDependencies, maybe due to a production install command? I am using pnpm.)

1. Does React Router 7 (framework) disallow devDependencies?

2. If so, "Why?"

Note: I am open to hearing critiques of "always use devDependencies." I am tempted to switch to "always use dependencies" to keep it simple for our developers. "Your developers should know the difference." is not helpful, but I am open to good material to help explain the difference. I personally prefer the definition of "runtime" and "others" for applications.

[sergiodxa]

You should keep runtime dependencies like @react-router/node as dependencies and not devDependencies

You can keep things like Vite, ESLint, Biome, and other build time dependencies as devDependencies.

[connorjs]

Could you share more why React Router (framework) disallows using devDependencies for @react-router/node though? Given @react-router/node does not end up in my production bundle itself; the bundled one (from Vite/esbuild, after treeshaking) does (per my understanding).

[tobigumo]

@sergiodxa
It would be great if the server runtime could be made unnecessary when ssr is set to false in the configuration (react-router.config.ts).
Is this difficult to achieve due to the framework mode works?

[swiing]

react-router dev also seem to require @react-router/node as a dependency, and not a devDependency.

An explanation of the why would help indeed.

[neopostmodern]

This is opinionated in a very hard to understand way. If there is a legitimate reason, the error message should be changed – but like the comments above, I'd much rather see the implementation changed.

[rossipedia]

Even in SPA mode, you still need something to serve the HTML during development. React Router provides this by performing SSR on your root route and rendering it's Layout + HydrateFallback, which is also exactly what happens when you run react-router build. To do this at dev time, it plugs in to the vite dev-server, which is built on top of node:http APIs.

When performing Server Side rendering, React Router needs to know what environment you're running in, because not all server environments behave the same way. The presence of a custom entry.server.tsx tells React Router "I'm taking full responsibility of server code execution, all good". Without a custom entry, React Router will use the default framework-provided server entry, which (as mentioned earlier) is built on top of node:http APIs. React Router can't realistically determine this for every possible app setup, so it takes the safe approach and errors if it can't find @react-router/node or a custom entry.server.tsx.

I suppose a reasonable approach here would be checking both dependencies and devDependencies if ssr:false. Probably wouldn't be high-effort either.