Debug test throws Error: No test suite found in file if project is located on D: drive

[armbzk]

Describe the bug

Description

• Running Debug test in vscode vitest extension fails with Error: No test suite found in file D:/gitea/armbzk/vitest-update/tests/dummy.test.mjs
• Error only occurs with Debug test - Run test succeeds without any error
• after copying the project to Windows C: drive Debug test works fine
• npx vitest run in console succeeds (also on D: drive)

Environment

• vscode 1.95.3
• OS: Windows_NT x64 10.0.26100 (Windows 11)
• Nodejs: 20.18.0
• npm 10.9.1
• vscode vitest extension v1.8.1
• vitest 2.1.7
• MSYS2 GNU bash, version 5.2.37(1)-release (x86_64-pc-msys)

Reproduction

Link to gihub repo: https://github.com/armbzk/vitest-error

tests/dummy.test.mjs:

import { describe, expect, it } from 'vitest';

describe('dummy tests', () => {
    it('should succeed', () => {
        expect(true).toBe(true);
    });
});

vitest.config.mts:

import { defineConfig } from 'vitest/config';

export default defineConfig({
    test: {
        environment: 'node',
        include: [
            'tests/*.test.{js,mjs}',
        ],
    },
});

package.json:

{
  "devDependencies": {
    "vitest": "^2.1.7"
  },
  "scripts": {
    "test": "npx vitest run"
  }
}

Output

Output in vscode DEBUG console:

C:\Program Files\nodejs\node.EXE c:\Users\armbzk\.vscode\extensions\vitest.explorer-1.8.1\dist\worker.js
Process exited with code 1

Error message in vitest test explorer:

Error: No test suite found in file D:/gitea/armbzk/vitest-update/tests/dummy.test.mjs
at runFiles (file:///digitea/armbzk/vitest-update/node_modules/@vitest/runner/dist/index.js:1254:11)
at startTests (file:///digitea/armbzk/vitest-update/node_modules/@vitest/runner/dist/index.js:1271:9)
at processTicksAndRejections (node:internal/process/task_queues:95:5)
at file:///digitea/armbzk/vitest-update/node_modules/vitest/dist/chunks/runBaseTests.3qpJUEJM.js:126:11
at withEnv (file:///d:/gitea/armbzk/vitest-update/node_modules/vitest/dist/chunks/runBaseTests.3qpJUEJM.js:90:5)
at run (file:///digitea/armbzk/vitest-update/node_modules/vitest/dist/chunks/runBaseTests.3qpJUEJM.js:112:3)
at runBaseTests (file:///d:/gitea/armbzk/vitest-update/node_modules/vitest/dist/chunks/base.BZZh4cSm.js:29:3)
at ForksBaseWorker.executeTests (file:///digitea/armbzk/vitest-update/node_modules/vitest/dist/workers/forks.js:27:7)
at execute (file:///d:/gitea/armbzk/vitest-update/node_modules/vitest/dist/workerjs:127:5)
at onMessage (file:///d:/gitea/armbzk/vitest-update/node_modules/tinypool/dist/entry/processjs:55:20)

Version

v1.8.1

Validations

• Check that you are using the latest version of the extension
• Check that there isn't already an issue that reports the same bug to avoid creating a duplicate.
• Check that this is a concrete bug. For Q&A open a GitHub Discussion or join our Discord Chat Server.
• The provided reproduction is a minimal reproducible example of the bug.

[sheremet-va]

What version of Vitest are you using?

[armbzk]

• vscode vitest extension v1.8.1
• vitest 2.1.7

[Skrypt]

I'm getting the same issue but it happens only when trying to debug a Vitest unit test in VS Code.
Running "npx vitest" works though.

using:

Vitest 2.1.8
VS Code Vitest extension v1.8.1
Node: 22.11

[Skrypt]

I reverted to
Vitest 2.0.0 and now it works.

[Skrypt]

Starts failing at 2.1.4

[Dykam]

Same as what Skrypt is experiencing.

Debugging in:
Vitest 2.1.3 works
Vitest 2.1.4 fails
Vitest 3.0.2 fails

VS Code Vitest extension 1.10.2
Node: 18.20.2

Personally I had no need to update to vitest 3 for other reasons, so I simply reverted. But this might become a problem in the future.

[tsirlucas]

Same issue with vitest 3. one thing i noticed is that if i dont import

import { describe, it } from 'vitest'

it shows the test cases correctly. but if i import it, i get the following error in output

EDIT: NVM the error log I had was unrelated.

EDIT 2: I managed to run the repo and updating vitest version to v3 makes it reproducible.

Main issues comes from getName function. It is now receiving callee as an SequenceExpression, which is not handled in there.

vscode/src/worker/collect.ts

Line 79 in a466c6b

const getName = (callee: any): string | null => {

Addin the following fixes the issue:

if (callee.type === 'SequenceExpression') {
      const memberExpression = callee.expressions.find((e) => e.type === 'MemberExpression')
      if (!memberExpression) {
        return null
      }
      return getName(memberExpression)
    }

But I dont have enough knowledge in ASTs to know how safe this is

[tsirlucas]

Correcting myself on previous comment: the problem seems to only happen if youre using vite 6

code sent to AST using vite 6:

const __vite_ssr_import_0__ = await __vite_ssr_import__("/node_modules/vitest/dist/index.js", {"importedNames":["describe","it"]});
(0,__vite_ssr_import_0__.describe)("should included", () => {
  (0,__vite_ssr_import_0__.it)("is included because of workspace plugin setting", () => {
  });
});

//# sourceMappingSource=vite-node
//# sourceMappingURL=data:application/json;charset=utf-8;base64,eyJ2ZXJzaW9uIjozLCJtYXBwaW5ncyI6IkFBQUE7R0FFQSxnQ0FBUyxtQkFBbUIsTUFBTTtBQUNoQywrQkFBRyxtREFBbUQsTUFBTTtBQUFBLEVBQUMsQ0FBQztBQUNoRSxDQUFDIiwibmFtZXMiOltdLCJpZ25vcmVMaXN0IjpbXSwic291cmNlcyI6WyJzaG91bGRfaW5jbHVkZWRfdGVzdC50cyJdLCJzb3VyY2VzQ29udGVudCI6WyJpbXBvcnQgeyBkZXNjcmliZSwgaXQgfSBmcm9tICd2aXRlc3QnXG5cbmRlc2NyaWJlKCdzaG91bGQgaW5jbHVkZWQnLCAoKSA9PiB7XG4gIGl0KCdpcyBpbmNsdWRlZCBiZWNhdXNlIG9mIHdvcmtzcGFjZSBwbHVnaW4gc2V0dGluZycsICgpID0+IHt9KVxufSlcbiJdLCJmaWxlIjoiL1VzZXJzL2x1Y2FzY29ycmVpYS9Eb2N1bWVudHMvd29ya3NwYWNlL2NoaWxpcGlwZXIvdnNjb2RlL3NhbXBsZXMvYmFzaWMvc3JjL3Nob3VsZF9pbmNsdWRlZF90ZXN0LnRzIn0=

while in v5:

const __vite_ssr_import_0__ = await __vite_ssr_import__("/node_modules/vitest/dist/index.js", {"importedNames":["describe","it"]});

__vite_ssr_import_0__.describe("should included", () => {
  __vite_ssr_import_0__.it("is included because of workspace plugin setting", () => {
  });
});

//# sourceMappingSource=vite-node
//# sourceMappingURL=data:application/json;charset=utf-8;base64,eyJ2ZXJzaW9uIjozLCJtYXBwaW5ncyI6IkFBQUEsQ0FBQTtBQUE2QjtBQUU3QiwrQkFBUyxtQkFBbUIsTUFBTTtBQUNoQywyQkFBRyxtREFBbUQsTUFBTTtBQUFBLEVBQUMsQ0FBQztBQUNoRSxDQUFDIiwibmFtZXMiOltdLCJpZ25vcmVMaXN0IjpbXSwic291cmNlcyI6WyJzaG91bGRfaW5jbHVkZWRfdGVzdC50cyJdLCJzb3VyY2VzQ29udGVudCI6WyJpbXBvcnQgeyBkZXNjcmliZSwgaXQgfSBmcm9tICd2aXRlc3QnXG5cbmRlc2NyaWJlKCdzaG91bGQgaW5jbHVkZWQnLCAoKSA9PiB7XG4gIGl0KCdpcyBpbmNsdWRlZCBiZWNhdXNlIG9mIHdvcmtzcGFjZSBwbHVnaW4gc2V0dGluZycsICgpID0+IHt9KVxufSlcbiJdLCJmaWxlIjoiL1VzZXJzL2x1Y2FzY29ycmVpYS9Eb2N1bWVudHMvd29ya3NwYWNlL2NoaWxpcGlwZXIvdnNjb2RlL3NhbXBsZXMvYmFzaWMvc3JjL3Nob3VsZF9pbmNsdWRlZF90ZXN0LnRzIn0=

Looks like (0,__vite_ssr_import_0__.describe) is parsed as the sequence... I wonder if its safe to assume we will always have a memberExpression as 2nd item. or at least inside the array. Id say its probably safe for us to just do the .find but AST's are new to me