Don't respect `conditions` on Vite 6

[sxzz]

Describe the bug

• resolve.conditions is not respected on Vite 6 with Vitest.
• It works on Vite 6 without Vitest.
• It works on Vite 5.

// vitest.config.ts
import { defineConfig } from 'vitest/config'

export default defineConfig({
  resolve: {
    conditions: ['dev'],
  },
})

Reproduction

https://stackblitz.com/~/github.com/sxzz/vitest-conditions-repro

• Run pnpm run test, and you will see the test has failed.
• Downgrade to vite@5, remove node_modules and pnpm-lock.yaml, and it works.

System Info

N/A

Used Package Manager

pnpm

Validations

• [X] Follow our Code of Conduct
• [X] Read the Contributing Guidelines.
• [X] Read the docs.
• [X] Check that there isn't already an issue that reports the same bug to avoid creating a duplicate.
• [X] Check that this is a concrete bug. For Q&A open a GitHub Discussion or join our Discord Chat Server.
• [X] The provided reproduction is a minimal reproducible example of the bug.

[colinlienard]

Also experiencing this issue, but I'm not using vite, it's the bump of vitest to v2.1.6 that is causing the issue for me, sticking to v2.1.5 for now

[sxzz]

Vitest uses Vite at its core, and Vitest v2.1.5 uses Vite 5, so this issue can be avoided on v2.1.5.

[sxzz]

Investigating: maybe related to Environment API

[sxzz]

Workaround: Adding environments.ssr.resolve.conditions can fix this issue.

import { defineConfig } from 'vitest/config'

export default defineConfig({
  resolve: {
    conditions: ['dev'],
  },
  environments: {
    ssr: {
      resolve: {
        conditions: ['dev'],
      },
    },
  },
})

[sheremet-va]

This is expected behaviour in Vite 6: https://vite.dev/guide/migration.html#general-changes

The default values for those options are updated to the corresponding values and ssr.resolve.conditions no longer uses resolve.conditions as the default value.

Vitest uses ssr environment in node Vitest environment (previously, ssr field in the config), and client environment in jsdom or happy-dom (previously, the root config)

We can add this to documentation

[sxzz]

IMHO, I don't think Vite 6's documentation is relevant to this issue. The breaking changes in Vite 6 only mention default values, but my reproduction uses a custom dev value instead, without default value.

I also tried setting ssr.resolve.conditions: ['dev'], but it doesn't work.

[sheremet-va]

The breaking changes in Vite 6 only mention default values, but my reproduction uses a custom dev value instead, without default value.

Vite 6 doesn't inherit resolve.conditions in SSR. Vitest uses SSR environment for the default node environment (from the reproduction). The only bug here is that Vitest doesn't inherit ssr.resolve.conditions. It treats should treat resolve.conditions the same way Vite does.

[sheremet-va]

You can override transformMode, by the way: https://vitest.dev/config/#testtransformmode (by default, it depends on the environment)

[sxzz]

I see. Maybe Vitest should release a major version due to the breaking change in Vite that significantly affects Vitest.

[sheremet-va]

I don't think this is part of Vitest API, this is how Vite works. If you don't want to use Vite 6, use Vite 5. We support both versions and just follow the configuration supported by the version of Vite that you are using.

[kolorfilm]

The breaking changes in Vite 6 only mention default values, but my reproduction uses a custom dev value instead, without default value.

Vite 6 doesn't inherit resolve.conditions in SSR. Vitest uses SSR environment for the default node environment (from the reproduction). The only bug here is that Vitest doesn't inherit ssr.resolve.conditions. It treats should treat resolve.conditions the same way Vite does.

I have the same problem. Can you maybe explain how this could look like in a workaround? Using vitest with happy dom.

Thank you!

[kolorfilm]

Somehow has the same issue.

[Cherry]

I think this needs to be considered a breaking change with vitest 2.1.5 -> 2.1.6. While I understand vitest supports 5.x and 6.x versions of vite now, in projects that don't use vite 6.x is now automatically used over 5.x in a patch version, which can result in drastically different behaviour.

For example, with Cloudflare's vitest-pool-workers which is used for testing Cloudflare Workers, they rely heavily on setting conditions: https://github.com/cloudflare/workers-sdk/blob/ff8f5ae03cd4a71bf7b468fcf3cd28bf064059ab/packages/vitest-pool-workers/src/config/index.ts#L110-L113

Most Cloudflare Workers don't use vite to build though, so don't have vite pinned to 5.x, resulting in breaking behaviour when upgrading from vitest 2.1.5 to 2.1.6, which just happened to me and led me down this rabbit hole.

[sheremet-va]

https://github.com/vitest-dev/vitest/releases/tag/v2.1.7 reverted support for Vite 6 for now. We will discuss with the team on how to introduce it without breaking changes.

[sheremet-va]

We will be releasing Vitest 3 in January with this change instead of Vitest 2.2. Both Vite 5 and Vite 6 will be supported, but the behaviour will depend on the version installed by your package manager.

[WtfJoke]

Does this also means vitest 3 (beside < vitest 2.17) will be the first version which supports vite 6 or will you also release a vitest 2.x version which supports vite 6?

[sheremet-va]

Does this also means vitest 3 (beside < vitest 2.17) will be the first version which supports vite 6 or will you also release a vitest 2.x version which supports vite 6?

There will be no more Vitest 2 versions. Vitest 3 is the first version that supports Vite 6 (excluding 2.1.6)

[unicornware]

@sheremet-va

conditions passed through NODE_OPTIONS are also not respected, which means internal imports are no longer resolved properly.

✘ [ERROR] Could not resolve "#colors"

    __tests__/reporters/verbose.mts:7:19:
      7 │ import colors from '#colors'
        ╵                    ~~~~~~~~~

  The module "./dist/colors.mjs" was not found on the file system:

    package.json:54:17:
      54 │       "default": "./dist/colors.mjs"
         ╵                  ~~~~~~~~~~~~~~~~~~~

  You can mark the path "#colors" as external to exclude it from the bundle, which will remove this
  error and leave the unresolved path in the bundle.

failed to load config from /Users/lex/Projects/FLDV/FLDV-P061/vitest.config.mts

note: the suggestion provided does not fix the error.

pinning vite to version 5.4.14 seems to be the only workaround. unfortunately, this isn't ideal. is this expected behavior?

[hi-ogawa]

Closing since this is an intended breaking change on Vitest 3 and OP's reproduction passes now with ssr.resolve.conditions: ['dev'] https://stackblitz.com/edit/github-bf27lxf7?file=vitest.config.ts

If you encounter an issue, please create a new issue with the reproduction. Thanks!