Vitest working with Nitro v2, but not with Nitro v3.0.1-alpha.0 #3659

Activity

1. theoludwig

   added

   pending triage

   on Oct 14, 2025
2. hi-ogawa commented on Oct 17, 2025

   

   hi-ogawa

   on Oct 17, 2025

   Contributor

   More actions

   For unit testing, server runtime is irrelevant, so nitro should be disabled. One quick way is to skip the plugin based on process.env.VITEST such as plugins: [!process.env.VITEST && nitro()]. Tanstack start's Nitro v2 plugin was essentially build only, so it didn't manifest any issues.

   👍React with 👍3Reacted by Gary Blackwood, Pooya Parsa and Robert Buchberger
3. theoludwig

   added a commit that references this issue on Oct 18, 2025

   chore: do not use nitro in vitest

   ...

   8255b85
4. theoludwig commented on Oct 18, 2025

   

   theoludwig

   on Oct 18, 2025

   Author

   More actions

   For unit testing, server runtime is irrelevant, so nitro should be disabled. One quick way is to skip the plugin based on process.env.VITEST such as plugins: [!process.env.VITEST && nitro()]. Tanstack start's Nitro v2 plugin was essentially build only, so it didn't manifest any issues.

   Ah, okay, it makes sense, thanks for the reply.
   I tried it, and indeed it seems to work: theoludwig/vite-nitro-issues@8255b85

   👍React with 👍1Reacted by Pooya Parsa
5. theoludwig

   closed this as completedon Oct 18, 2025
6. pi0

   reopened this on Oct 19, 2025
7. pi0 commented on Oct 19, 2025

   

   pi0

   on Oct 19, 2025

   Member

   More actions

   reopening issue to try to make nitro plugin behavior smarter when running within tests.
8. pi0

   added

   enhancementNew feature or requestNew feature or request

   v3

   and removed

   pending triage

   on Oct 19, 2025
9. kricsleo commented on Oct 21, 2025

   

   kricsleo

   on Oct 21, 2025

   Member

   More actions

   behavior smarter when running within tests.

   Means Nitro could skip internally when detected running with tests? If that's it, I can help. 🙌
10. theoludwig commented on Nov 10, 2025

    

    theoludwig

    on Nov 10, 2025

    Author

    More actions

    behavior smarter when running within tests.

    Means Nitro could skip internally when detected running with tests? If that's it, I can help. 🙌

    Is the above could be a solution? @pi0

    For now users, must have in their vite.config.ts the following:

    import { nitro } from "nitro/vite"
    import { defineConfig } from "vite"
    
    const IS_TEST = process.env["NODE_ENV"] === "test"
    
    export default defineConfig({
      plugins: [
        ...(!IS_TEST ? [nitro()] : []),
      ],
    })
11. pi0 commented on Nov 10, 2025

    

    pi0

    on Nov 10, 2025

    Last edited by pi0

    Member

    More actions

    @theoludwig yes it is a good workaround.

    i am investigating first-class vitest support, nitro already can setup a good vitest runner enviornment small changes needed.

    👍React with 👍1Reacted by Théo LUDWIG
12. hi-ogawa commented on Nov 11, 2025

    

    hi-ogawa

    on Nov 11, 2025

    Last edited by hi-ogawa

    Contributor

    More actions

    I also wonder whether completely disabling nitro plugin is good. For example, it might be nice if some nitro specific module convention (virtual module etc.) works inside Vitest.

    (For the context, for example, sveltekit plugin can work with Vitest and it allows $lib/.., $env etc. module convention.)

    👍React with 👍1Reacted by Pooya Parsa
13. pi0 commented on Nov 18, 2025

    

    pi0

    on Nov 18, 2025

    Member

    More actions

    /cc @juliusmarminge. You should disable plugin for test environment.

    Probably best we do it out of the box until vitest support lands.
14. theoludwig commented on Nov 23, 2025

    

    theoludwig

    on Nov 23, 2025

    Author

    More actions

    When fixing this issue, it might also be worth to check support for Storybook as well: storybookjs/storybook#33010
15. pi0

    marked Nitro plugin breaks vitest monorepo feature #4144 as a duplicate of this issue on Mar 23, 2026
16. pi0x

    added

    tanstack

    on Sep 2, 2026
17. dlukt commented on Oct 1, 2026

    

    dlukt

    on Oct 1, 2026

    More actions

    Hi 👋 — adding another (distinct) manifestation of this issue with a full diagnosis, in case it helps pin the root cause.

    Environment

    • Node 24, Vite 8.3.1, Vitest 4.1.11
    • nitro 3.0.260903-beta, @tanstack/react-start 1.168.60, react 19.3.0
    • TanStack Start app using the nitro() vite plugin alongside tanstackStart()

    Symptom

    vitest run prints this on every run (tests still pass — it's console noise from the dev runner), plus the close timed out after 10000ms / hanging-process behavior from #4144:

    ReferenceError: module is not defined
        at .../node_modules/react/index.js:6:3
        at ESModulesEvaluator.runInlinedModule (.../vite/dist/node/module-runner.js:811:163)
        at ModuleRunner.directRequest (.../vite/dist/node/module-runner.js:1272:80)
    

    Bisected the plugin set: the error only appears when both nitro() and tanstackStart() are present — each one alone is clean.

    Mechanism (traced via instrumentation)

    1. Nitro's dev worker (dist/runtime/internal/vite/dev-worker.mjs) registers env runners — for this setup:
       • nitro → nitro/dist/runtime/internal/vite/dev-entry.mjs
       • ssr → @tanstack/react-start/dist/plugin/default-entry/server.ts
         and eagerly imports each entry (this.entry = await this.runner.import(this.entryPath)).
    2. The ssr entry graph is: server.ts → @tanstack/react-start/server → @tanstack/react-start-server → StartServer.js, whose first line is a bare import "react".
    3. react resolves to its raw CJS build (react/index.js). By the time the runner requests it, the specifier is a resolved file path, and vite's fetchModule() only takes the externalize branch for bare specifiers with an importer (url[0] !== "." && url[0] !== "/") — path-form URLs always go through transformRequest and get inlined. The ESModulesEvaluator then evaluates the CJS file as ESM → module is not defined. (resolve.external / ssr.external are never consulted for these fetches, so they can't intercept it.)
    4. Under vite dev this doesn't happen because react-start adds optimizeDeps.include: ["react", ...] for the server environments, so react is pre-bundled to ESM. Under vitest, react-start's needsOptimizeDeps is false (vitest sets optimizeDeps.noDiscovery = true), so no pre-bundle happens and the raw CJS file is what reaches the runner.
    5. The error is caught by the dev-worker reload path (console.error(error); this.entryError = error), which is why it only surfaces as noise and doesn't fail the run.

    So it looks like the intersection of: nitro v3's dev runner eagerly evaluating the SSR entry + react-start disabling deps optimization under vitest (see also TanStack/router#6074, which is the flip side — it fixes dual-react-instance hook errors by skipping optimizeDeps in VITEST).

    Reproduction

    A vite config with just:

    import { defineConfig } from 'vite'
    import { nitro } from 'nitro/vite'
    import { tanstackStart } from '@tanstack/react-start/plugin/vite'
    
    export default defineConfig({ plugins: [nitro(), tanstackStart()] })

    plus any passing test file, triggers it with vitest run. vite dev and vite build are both unaffected (dev serves SSR fine, no errors).

    Workaround

    Same as suggested in #4144 — skip the plugin under vitest:

    ...(process.env.VITEST ? [] : [nitro()]),

    Happy to provide a full standalone repro repo if useful. Thanks for the work on v3! 🙏
18. pi0x commented on Oct 18, 2026

    

    pi0x

    on Oct 18, 2026

    Contributor

    More actions

    Vitest support landed in #4748, so the original report may be fixed on the latest beta. Could you check? The newer report above (CJS react inlined in the ssr env runner when using TanStack Start under Vitest) looks like a separate problem and might be easier to track in its own issue.

    Triaged with AI assistance.
19. pi0

    closed this as completedon Oct 18, 2026
20. pi0 commented on Oct 18, 2026

    

    pi0

    on Oct 18, 2026

    Member

    More actions

    (vitest support in next release and currently on v3 nightly)