Changed testNamePattern behavior breaks IntelliJ / WebStorm (vitest 0.34.4)

[segrey]

Describe the bug

testNamePattern format has been changed in vitest 0.34.4 (#4071). Unfortunately, it broke running a single test/suite in IntelliJ / WebStorm (WEB-62946).
The difference is that, previously, testNamePattern had a leading space always. Now, testNamePattern doesn't have a leading space, but previously released versions of IntelliJ / WebStorm still pass testNamePattern starting with a space.

Unfortunarely, it will be hard to release a hotfix of IntelliJ/WebStorm quickly, because of the release schedule. Even if we would release it, our users would be required to upgrade their IDEs (which would be inconvenient for the users).

Sorry, may I ask you to restore the leading space in testNamePattern for now? I'll fix IntelliJ / WebStorm in the next version (2023.3) to support both formats of testNamePattern. I guess it would be OK to drop the leading space completely in 2024 Q1 - once WebStorm 2024.1 is released, to have two major WebStorm versions supporting both testNamePattern formats.

What do you think? @sheremet-va @Dunqing @jaswrks

Reproduction

For example, to run basic test only in vitest 0.34.3, one should use the following command line:

./node_modules/.bin/vitest --run '--testNamePattern=^ basic$' test/basic.test.ts

 RUN  v0.34.3 /Users/sergey.simonchik/sandbox/vitest-basic

 ✓ test/basic.test.ts (3)
   ✓ basic
   ↓ my suite (2) [skipped]
     ↓ foo [skipped]
     ↓ bar [skipped]

 Test Files  1 passed (1)
      Tests  1 passed | 2 skipped (3)
   Start at  12:14:49
   Duration  142ms (transform 23ms, setup 0ms, collect 15ms, tests 1ms, environment 0ms, prepare 41ms)

Using the same command line doesn't work with vitest 0.34.4:

➜  vitest-basic git:(master) ✗ ./node_modules/.bin/vitest --run '--testNamePattern=^ basic$' test/basic.test.ts

 RUN  v0.34.4 /Users/sergey.simonchik/sandbox/vitest-basic

 ↓ test/basic.test.ts (3) [skipped]
   ↓ basic [skipped]
   ↓ my suite (2) [skipped]
     ↓ foo [skipped]
     ↓ bar [skipped]

 Test Files  1 skipped (1)
      Tests  3 skipped (3)
   Start at  12:43:12
   Duration  136ms (transform 24ms, setup 0ms, collect 13ms, tests 0ms, environment 0ms, prepare 40ms)

System Info

System:
    OS: macOS 13.5.2
    CPU: (10) arm64 Apple M1 Max
    Memory: 3.46 GB / 32.00 GB
    Shell: 5.9 - /bin/zsh
  Binaries:
    Node: 20.6.1 - ~/.nvm/versions/node/v20.6.1/bin/node
    Yarn: 1.22.19 - /opt/homebrew/bin/yarn
    npm: 9.8.1 - ~/.nvm/versions/node/v20.6.1/bin/npm
    pnpm: 7.14.0 - ~/.nvm/versions/node/v20.6.1/bin/pnpm
  Browsers:
    Chrome: 116.0.5845.179
    Safari: 16.6
  npmPackages:
    vitest: 0.34.4 => 0.34.4

Used Package Manager

npm

Validations

• Follow our Code of Conduct
• Read the Contributing Guidelines.
• Read the docs.
• 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]

I think reverting it is fine until you can support it.

[Dunqing]

Can we fix it in a different webstorm-compatible way?

E.g. by removing the leading space returned by getTaskFullName?

vitest/packages/runner/src/utils/collect.ts

Line 30 in 070bc9e

if (namePattern && !getTaskFullName(t).match(namePattern))

[segrey]

@Dunqing I think any fix supporting leading space in the passed testNamePattern would work.

[segrey]

I've opened a simple PR #4104. Please take a look. Would be great to release a new vitest version with the fix included.

[jaswrks]

No objection from me either way. Big thanks to those who worked on this.

I will say, @segrey, it would be nice if someone acknowledged the following ... Submitting a PR that reintroduces a bug into an open source package they depend on is less than ideal. Particularly since it seems like (I can't be sure), but it seems like a PR that fixed this bug when you originally encountered it would have been a far better path to have taken vs. now needing to open a PR that reintroduces a bug they worked around. Contribute to open source ftw!

[segrey]

@jaswrks Thanks for the feedback. I think reintroducing bugs is not ideal in any project. Actually, PR #4104 with a straightforward revert was a starting point to discuss better solutions. No better solutions were suggested => the PR was merged.

For completeness, I've opened #4119 aiming to keep #4045 closed, but the new solution is not ideal either.