fix: re-apply default conditions if using vite 6 or later

[thebanjomatic]

Fixes #7070

Description

Vite 6 no longer applies default conditions when you override resolve.conditions. This PR adds them back conditionally based on the vite version.

Please don't delete this checklist! Before submitting the PR, please make sure you do the following:

• It's really useful if your PR references an issue where it is discussed ahead of time. If the feature is substantial or introduces breaking changes without a discussion, PR might be closed.
• Ideally, include a test that fails without this PR but passes with it.
• Please, don't make changes to pnpm-lock.yaml unless you introduce a new test example.

Tests

• Run the tests with pnpm test:ci.

Documentation

• If you introduce new functionality, document it. You can run documentation with pnpm run docs command.

Changesets

• Changes in changelog are generated from PR name. Please, make sure that it explains your changes in an understandable manner. Please, prefix changeset messages with feat:, fix:, perf:, docs:, or chore:.

[netlify]

✅ Deploy Preview for vitest-dev ready!

Built without sensitive environment variables

Name	Link
🔨 Latest commit	3c7604d
🔍 Latest deploy log	https://app.netlify.com/sites/vitest-dev/deploys/6759f3a037b5740008c2d208
😎 Deploy Preview	https://deploy-preview-7071--vitest-dev.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

---

To edit notification comments on pull requests, go to your Netlify site configuration.

[thebanjomatic]

I don't love that the vite migration docs say:

For example, if you previously specified ['custom'] for resolve.conditions, you need to specify ['custom', ...defaultClientConditions] instead.

which implies that we should just be doing:

clientConditions: ['node', ...defaultClientConditions],

but there is some subtlety in that in vite 5, 'node' and 'browser' weren't actually part of the default conditions, but instead it used the browser option for the resolve function as follows:

resolve({
  ...
  browser: targetWeb && !additionalConditions.has('node')
  conditions,
  ...
});

So in the case of vitest passing "node" as an additional condition it would disable the browser resolve, but if node wasn't passed in, it would infer 'browser' resolve behavior from that rather than using conditions. You couldn't previously get in a case where you had both "browser" and "node" conditions, but when just using conditions in vite 6 you can.

If you want the same behavior as before, we need to remove "browser" from vite's default conditions, and add the node condition instead.

[hi-ogawa]

If you want the same behavior as before, we need to remove "browser" from vite's default conditions, and add the node condition instead.

I think we need to go with this. Running browser exports on jsdom/happy-dom will likely break a lot, for example #7215.

To keep the intention of Vitest's conditions: ["node"] on Vite 5, I think what we need is essentially setting defaultServerConditions all the time, namely something like:

const { defaultServerConditions } = await import("vite");
{
  resolve: {
    conditions: defaultServerConditions
  },
  ssr: {
    resolve: {
      conditions: defaultServerConditions
    }
  }
}

[thebanjomatic]

@sheremet-va assuming this change looks good for the vitest 3.x release, is there any chance of back-patching it to 2.1.9 while waiting for the official 3.x release?

[sheremet-va]

Vitest 2 doesn’t support Vite 6

[thebanjomatic]

The 2.1.7 release notes implied a soft support:

We will enable support for it later. In the meantime, you can still use pnpm.overrides or yarn resolutions to override the vite version in the vitest package - the APIs are compatible.

But that was under the assumption the api's were compatible which doesn't appear to be the case. I'm ok waiting, but thought I'd ask.

[sheremet-va]

The API is compatible, only default config values have breaking changes

[thebanjomatic]

@sheremet-va would it be possible to get this looked at again for a future vitest 3 alpha release?

[hi-ogawa]

Can you also test CI with Vite 6? You can temporarily bump this version and commit.

vitest/package.json

Line 65 in e2e0658

"vite": "^5.4.0",

---

Also can you add a new test which breaks on Vite 6? I think one difference is module and development conditions are automatically added on Vite 5, but that doesn't exist with Vite 6.
(I made a quick repro https://github.com/hi-ogawa/reproductions/tree/main/vitest-7071-vite6-conditions)

[sheremet-va]

why do we need to import this dynamically?

[thebanjomatic]

Good question. The exports don't exist on vite5 so I think my intention was to only import them for vite 6. However, I think maybe they would just come through as undefined with a static import, so I'll test that and make the change if that's the case

[netlify]

✅ Deploy Preview for vitest-dev ready!

Built without sensitive environment variables

Name	Link
🔨 Latest commit	d4c3e83
🔍 Latest deploy log	https://app.netlify.com/sites/vitest-dev/deploys/678859a40d0a240008cb1497
😎 Deploy Preview	https://deploy-preview-7071--vitest-dev.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

---

To edit notification comments on pull requests, go to your Netlify site configuration.

[thebanjomatic]

@hi-ogawa / @sheremet-va Thanks for your help with the revisions.

I was able to add a test case for this which fails in vite 6 without this change, but succeeds with the change. I was trying to reuse the existing fixture for the "conditions-cli" test case, but I couldn't find a way to add a check for the "module" condition without breaking the other tests. The simplest idea of just wrapping the existing conditions in a "module" condition, unfortunately doesn't work in Vite 5 but does in Vite 6, so I fell back on adding a simpler reproducer test more in line with what was suggested.

Vite 5 test run: https://github.com/vitest-dev/vitest/actions/runs/12796508495?pr=7071
Vite 6 test run: https://github.com/vitest-dev/vitest/actions/runs/12796723653?pr=7071

There were failures in the Vite 6 test run, but I don't think they are related, and some of them happened before and some after the new tests that were added. There seemed to be 3 types of failures:

  FAIL  test/browser-multiple.test.ts > automatically assigns the port
  AssertionError: expected [ 'http://localhost:63315/', 'http://localhost:63317/' ] to include 'http://localhost:63316/'

  FAIL   threads  test/imports.test.ts > importing special files from node_modules > importing wasm with ?raw query
  AssertionError: expected '' to be '(module)' // Object.is equality

  FAIL   v8  test/vue.test.ts > coverage results matches snapshot
  Error: Snapshot `coverage results matches snapshot 1` mismatched
  - Expected
  + Received
  @@ -1,11 +1,11 @@
    {
      "branches": {
  -     "covered": 5,
  +     "covered": 7,
  -     "pct": 83.33,
  +     "pct": 87.5,
        "skipped": 0,
  -     "total": 6,
  +     "total": 8,
      }, 

I have reverted the temporary vite 6 upgrade commit.

[pkg-pr-new]

@vitest/browser

npm i https://pkg.pr.new/@vitest/browser@7071

@vitest/coverage-istanbul

npm i https://pkg.pr.new/@vitest/coverage-istanbul@7071

@vitest/expect

npm i https://pkg.pr.new/@vitest/expect@7071

@vitest/mocker

npm i https://pkg.pr.new/@vitest/mocker@7071

@vitest/coverage-v8

npm i https://pkg.pr.new/@vitest/coverage-v8@7071

@vitest/pretty-format

npm i https://pkg.pr.new/@vitest/pretty-format@7071

@vitest/runner

npm i https://pkg.pr.new/@vitest/runner@7071

@vitest/snapshot

npm i https://pkg.pr.new/@vitest/snapshot@7071

@vitest/spy

npm i https://pkg.pr.new/@vitest/spy@7071

@vitest/ui

npm i https://pkg.pr.new/@vitest/ui@7071

@vitest/utils

npm i https://pkg.pr.new/@vitest/utils@7071

vite-node

npm i https://pkg.pr.new/vite-node@7071

vitest

npm i https://pkg.pr.new/vitest@7071

@vitest/web-worker

npm i https://pkg.pr.new/@vitest/web-worker@7071

@vitest/ws-client

npm i https://pkg.pr.new/@vitest/ws-client@7071

commit: 0a6f843

[hi-ogawa]

Thanks, looks good to me! I pushed some cleanup for tests.

Btw, I'm guessing your original repro was hit by tslib's module and node condition https://publint.dev/[email protected]. Can you verify your repro is fixed using #7071 (comment)?

There were failures in the Vite 6 test run, but I don't think they are related, and some of them happened before and some after the new tests that were added. There seemed to be 3 types of failures:

Ah, I should've given you a heads up. There are some tests failing due to other things. It should be fine to not worry about them for now.