search

vitest-dev / vitest

Next generation testing framework powered by Vite.
https://vitest.dev
MIT License
12.65k stars 1.13k forks source link

Vitest workspace - config from packages leaking into other packages #5541

Open seanogdev opened 5 months ago

seanogdev commented 5 months ago

Describe the bug

Noticing that when we run vitest in a workspace, there are certain side effects happening.

For example, we have https://github.com/unplugin/unplugin-auto-import installed, this generates an eslint file that gives us a file to generate globals for what is auto importable so eslint doesnt complain.

Noticing that when we run vitest in the root, the generate file gets added to other packages and too the workspace

Group 1

Reproduction

https://github.com/seanogdev/vitest-workspace-issue

System Info

System:
    OS: macOS 14.4.1
    CPU: (10) arm64 Apple M1 Max
    Memory: 195.55 MB / 32.00 GB
    Shell: 3.7.1 - /opt/homebrew/bin/fish
  Binaries:
    Node: 20.11.1 - ~/Library/Caches/fnm_multishells/5007_1713108944555/bin/node
    Yarn: 1.22.19 - ~/Library/Caches/fnm_multishells/5007_1713108944555/bin/yarn
    npm: 10.2.4 - ~/Library/Caches/fnm_multishells/5007_1713108944555/bin/npm
    pnpm: 8.15.1 - ~/Library/Caches/fnm_multishells/5007_1713108944555/bin/pnpm
  Browsers:
    Chrome: 123.0.6312.124
    Safari: 17.4.1
  npmPackages:
    vitest: ^1.5.0 => 1.5.0

Used Package Manager

pnpm

Validations

AriPerkkio commented 5 months ago

Does this happen with vitest@1.4.0 or just 1.5.0?

seanogdev commented 5 months ago

Just tested, it appears to be happening in both

hi-ogawa commented 5 months ago

@seanogdev I tested with "pnpm": { "overrides": { "vitest": "1.4.0" } } and it's generating .eslintrc-auto-import.json at the root, so this change might be due to https://github.com/vitest-dev/vitest/pull/5476 since v1.5.0. (Btw, you had packages/config/pnpm-lock.yaml but I wasn't sure if it's intended, so I tested before testing)

Btw, where is this file supposed to be generated? Is it at root or at packages/app?

Also this might be partially a plugin side issue with current Vitest workspace's limitation https://github.com/vitest-dev/vitest/issues/5277#issuecomment-2049955873 since it looks like process.cwd is used here https://github.com/unplugin/unplugin-auto-import/blob/128d050107af1b57ffe2fe2b32018e4110042bde/src/core/ctx.ts#L36 and also relative path https://github.com/unplugin/unplugin-auto-import/blob/128d050107af1b57ffe2fe2b32018e4110042bde/src/core/ctx.ts#L48

It looks like the plugin supports eslint.filepath, so for now, I think you can explicitly set it like this:

    AutoImport({
      imports: ["vue"],
      eslintrc: {
        enabled: true,
        filepath: fileURLToPath(
          new URL("../../.eslintrc-auto-import.json", import.meta.url)
        ),
      },
    })
gkubisa commented 5 months ago

I started experiencing this issue, with and without vitest.workspace.js, when I installed the vitest.explorer extension. I work around it simply by resolving the relative paths explicitly, similar to how you suggested it above.

It looks like the issue has something to do with the current working directory because:

given a directory structure like this:

and package/b/vite.config.js like this:

AutoImport({
  imports: ["vue"],
  eslintrc: {
    enabled: true,
    filepath: ".eslintrc-auto-import.json"
  },
})

the .eslintrc-auto-import.json file is generated, seemingly randomly, at one of these locations:

instead of always at the location relative to package/b/vite.config.js, which is package/b/.eslintrc-auto-import.json in this case.

sqs commented 4 months ago

I am seeing an issue where a define of process.env.FOO in one workspace is affecting another when running vitest run from the root. The workspace that has the define imports TypeScript files from the other workspace using relative path imports. This means that technically the build must be done differently for the 2 different test invocations, but it seems only a single build is occurring that has the defines undesirably applied.

My workaround is to only apply the defines when Vite is building and not when Vitest is testing, which works for my needs:

    // TODO(sqs): Workaround for
    // https://github.com/vitest-dev/vitest/issues/5541#issuecomment-2093886235; we only want and
    // need to apply the `define`s when building, not when testing. The `define`s leak into the
    // `agent` tests and cause some failures because process.env.CODY_SHIM_TESTING gets `define`d to
    // `false`.
    define: process.env.VITEST ? null : {
        ...Object.fromEntries(
            Object.entries(fakeProcessEnv).map(([key, value]) => [
                `process.env.${key}`,
                JSON.stringify(value),
            ])
        ),
    },