react-router Vite plugin breaks Vitest when importing packages that distribute invalid ESM code in the `import` condition

[remorses]

I'm using React Router as a...

framework

Reproduction

https://stackblitz.com/edit/github-qah1efnd?file=package.json

When running pnpm vitest the test fails, because react router vite plugin adds the import condition and a package in the @sentry/node dependencies distributes invalid ESM without the .js extension

Vitest Vite config should not have the module condition in ssr as you can see from this comment

System Info

System:
    OS: macOS 15.5
    CPU: (10) arm64 Apple M2 Pro
    Memory: 85.98 MB / 16.00 GB
    Shell: 5.9 - /bin/zsh
  Binaries:
    Node: 24.2.0 - ~/.local/share/pnpm/node
    Yarn: 1.22.22 - /usr/local/bin/yarn
    npm: 11.3.0 - ~/.local/share/pnpm/npm
    pnpm: 10.12.1 - ~/.local/share/pnpm/pnpm
    bun: 1.2.9 - ~/.bun/bin/bun
  Browsers:
    Chrome: 137.0.7151.120
    Safari: 18.5
  npmPackages:
    @react-router/dev: ^7.6.2 => 7.6.2
    @react-router/fs-routes: ^7.6.2 => 7.6.2
    @react-router/node: ^7.6.2 => 7.6.2
    @react-router/serve: ^7.6.2 => 7.6.2
    react-router: ^7.6.2 => 7.6.2
    vite: ^6.3.5 => 6.3.5

Used Package Manager

npm

Expected Behavior

Vitest should work even if the react router plugin is applied in the vite config

Actual Behavior

Adding react router Vite plugin breaks Vitest tests when you use a package like @sentry/node

[Andarist]

When running pnpm vitest the test fails, because react router vite plugin adds the import condition and a package in the @sentry/node dependencies distributes invalid ESM without the .js extension

To be fair, if the package is misconfigured - that's the issue on their end and not in a consuming tool. You could report this particular problem to the Sentry team.

[remorses]

This problem happens with @sentry/node package which is a super popular package, unfortunately JavaScript programmers are too dumb to publish working packages so tooling needs to account for that

[Andarist]

I don't quite agree with that statement as it leads to massive cracks in the ecosystem and lack of portability between tools. It poses an additional risk of a package maintainer publishing a broken package after testing it. Package maintainers can't test a package against all potential consuming tools and they might end up testing using a tool that decides to do custom (incorrect) things.

But either way, everyone might have their own opinion on this matter 😉 Going back to the topic...

This looks like a Vite/Vite Node/Vitest bug to me. It's hard to tell on the spot where things go rogue.

1. Vitest decides to run module here
2. This ends up discovering a @sentry/node dependency here and resolving it to node_modules/@sentry/node/build/esm/index.js
3. Then that gets passed to this._fetchModule and externalize is returned with the same value here
4. so it gets passed to interopedImport and that ends up calling native dynamic import
5. eventually, node itself errors when trying to load @opentelemetry/semantic-conventions (so the issue doesn't even directly related to @sentry/node, but rather its dependency)

Note that the above analysis assumes the fix from #13871 . But even with that Vitest resolved using a module condition but yet decided to externalize the module! That doesn't make sense at all if we consider externalConditions: ['node', 'development'] - this value doesn't allow it to use module condition for externalized packages.

This clearly indicates the bug is there and not with the opentelemetry package. In fact, opentelemetry's modules are OK and valid... as long as they don't contain import conditions pointing to the same files as the ones pointed by module condition. Those are 2 different conditions and they don't quite play by the same rules

[remorses]

I was only half kidding, I am a bit angry with the guys working at opentelemetry and Sentry that decided to continue ship broken code even after being told so many times, Sentry should choose their dependencies better.

Thank you for the investigation on the issue