During type checking, the type files in vitest and vite cannot find the type they use

[yingpengsha]

Describe the bug

My type checking use case passed without a hitch, but there was a problem with the type inside the library itself

• log: https://github.com/Blueprint-Breeze/aabb/actions/runs/7460993639/job/20300207519#step:7:50

⎯⎯⎯⎯⎯⎯ Typecheck Error ⎯⎯⎯⎯⎯⎯⎯
Error: Error: node_modules/.pnpm/@[email protected]/node_modules/@vitest/utils/dist/error.d.ts(4,58): error TS2304: Cannot find name 'WeakKey'.
Error: node_modules/.pnpm/@[email protected]/node_modules/@vitest/utils/dist/error.d.ts(6,96): error TS2304: Cannot find name 'WeakKey'.
Error: node_modules/.pnpm/@[email protected]/node_modules/@vitest/utils/dist/error.d.ts(6,133): error TS2304: Cannot find name 'WeakKey'.
Error: node_modules/.pnpm/[email protected]_@[email protected]/node_modules/vite/dist/node/index.d.ts(6,41): error TS2307: Cannot find module 'rollup/parseAst' or its corresponding type declarations

Reproduction

• repo: https://github.com/Blueprint-Breeze/aabb
• log: https://github.com/Blueprint-Breeze/aabb/actions/runs/7460993639/job/20300207519#step:7:50

System Info

> This is my local environment configuration, of course, can also reproduce the previous problem

  System:
    OS: macOS 13.4
    CPU: (12) arm64 Apple M2 Pro
    Memory: 122.00 MB / 32.00 GB
    Shell: 5.9 - /bin/zsh
  Binaries:
    Node: 16.20.1 - ~/.nvm/versions/node/v16.20.1/bin/node
    Yarn: 1.22.19 - ~/.nvm/versions/node/v16.20.1/bin/yarn
    npm: 8.19.4 - ~/.nvm/versions/node/v16.20.1/bin/npm
    pnpm: 7.33.6 - ~/.nvm/versions/node/v16.20.1/bin/pnpm
    bun: 1.0.0 - ~/.bun/bin/bun
  Browsers:
    Chrome: 120.0.6099.199
    Edge: 120.0.2210.121
    Safari: 16.5

Used Package Manager

pnpm

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.

[hi-ogawa]

The issue might be related to

• Cannot find module 'rollup/parseAst' after vite 5 got released #4567
• Vite 5 vitejs/vite#12466 (comment)

Probably your tsconfig is somewhat old-ish compared to what Vite/Vitest expect and having "moduleResolution": "Bundler" and "lib": ["ESNext"] might be recommended, something like:

vitest/tsconfig.base.json

Lines 1 to 6 in 9ec3f74

	{
	"compilerOptions": {
	"target": "ESNext",
	"lib": ["esnext"],
	"module": "ESNext",
	"moduleResolution": "Bundler",

Or disabling type check inside dependencies would probably workaround this and somewhat common thing to do as well:

vitest/tsconfig.base.json

Line 37 in ca76f45

"skipLibCheck": true

For some reason, I cannot run your repo locally (somehow Vitest is stuck) so I couldn't verify though. It might be nice if you can minimize repro further.

[mrazauskas]

Upgrading TypeScript and running tsc --noEmit in the reproduction repo, gives: "Cannot find module 'rollup/parseAst' or its corresponding type declarations." This looks like #4567. Following the thread one can find a workaround in rollup/rollup#5199. As already mentioned, the suggestion is to use moduleResolution: "bundler". I just wanted to make it clear what is the reason here.

moduleResolution: "bundler" make tsc --noEmit work on TypeScript 5.2.

Running tsc --noEmit with TypeScript 5.0 and 5.1 complains that it "Cannot find name 'WeakKey'" in several places of @vitest/utils. It is not easy to browse through TypeScript's repo, but seems like the WeakKey type was add in microsoft/TypeScript#54195. If I get it right, the WeakKey type shipped with TypeScript 5.2-beta.

Does it mean vitest --typecheck supports only TypeScript 5.2 and up? And/or requires moduleResolution: "bundler"? (By the way, with these changes and also "skipLibCheck": true added, it still gets stuck for me in the reproduction repo.)

Should these details be added to Vitests documentation, perhaps?

[yingpengsha]

@hi-ogawa I'd like to express my deep appreciation for the solution you provided. It was very detailed and helped me successfully resolve this problem.

As for the issue you mentioned about not being able to reproduce the problem on your end, it might be because I updated the code afterwards. If you wish to reproduce it, I have created a separate branch with the original code at repord/vitest-type-issue .

However, I have encountered a new issue, which you also noticed in my latest code. It seems that Vitest is getting stuck during execution. I will create a separate reproduction to confirm this issue and will open another issue for discussion once it's consistently reproducible.

Also, I believe the suggestion made by @mrazauskas is valuable. I think the results of the testing phase should be as close as possible to the state during development. It's always puzzling when unexpected issues arise during testing that weren't anticipated during development.

I'll close this issue and open it again if there are further discussions.