-
-
Notifications
You must be signed in to change notification settings - Fork 1.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
False negative with typecheck enabled #6151
Comments
There is a reason why export default defineWorkspace([
{
extends: './vitest.config.ts',
},
{
extends: './vitest.config.ts',
typecheck: {
enabled: true,
include: [sameInclude],
}
},
]) |
I see, agreed would be good if there was an error to avoid false negatives. In the meantime, what would you recommend for https://github.com/colinhacks/zod/tree/v4? That's using a vitest.root.ts: https://github.com/colinhacks/zod/blob/v4/vitest.root.ts Should vitest.root.ts become vitest.workspace.ts? That's what I did in this PR on zod: colinhacks/zod#3647 - does that look about right to you? (it does seem to resolve the problem) |
I ended up fixing this problem in Zod import * as z from "../src/index"
export {z}; I think the current behavior of It doesn't make sense to me that a file is either a "runtime test file" or "type test file". This doesn't actually seem to be true, because my test files ( It seems source files only get type checked when they're imported from a The pattern that most library authors want is this:
Here's the set of steps I took In trying to achieve this:
|
It's a bug: #5868
Here is the comment on why this is hard to achieve: #5019 (comment) The team agrees that it should be possible to run both at the same time: But typechecking is low on our priorities at the moment. What I can do right now is throw an error if they intersect or introduce another bug where if the do, they will just run, but the errors will be reported as source errors. |
Since the consensus seems to be typecheck and runtime tests should be able to overlap, I would urge you to reconsider excluding test.each (and the rest of the APIs that error out at typecheck); if the main problem is test names, is there a way to just use the argument to the test method, regardless of what the actual runtime name of the generated tests would be? e.g.: I have a codebase that has a few test.each calls, and it uses types autogenerated from swagger files, it would be great if vitest could tell me immediately (as test results to keep everything under one umbrella) if any tests have typecheck errors when the types get updated - right now they pass even if vscode/typescript show type errors. But if test.each will still error out I can't enable typecheck for the entire project. I also tried converting test.each to for loops, and that seems to work to some extent, but the tests are no longer discoverable for example in vscode. I can probably live with that for now, or maybe the vscode extension could be improved instead to detect these tests (but I'm guessing it's not that simple). Do you know if there's any other consequences to this? Edit: I was slightly wrong, tests in a for loop are detected fine when typecheck is disabled, they only disappear from test explorer when typecheck is enabled... if I have type errors in those files - that must mean this approach could work fine when these changes are made! |
Describe the bug
The following test passes!
With this config:
Note: commenting out the whole
typecheck
prop makes the test fail as expected, as does commenting outtypecheck.include
.Reproduction
https://stackblitz.com/edit/vitest-dev-vitest-hw9uz6?file=test/huh.test.ts
You can also repro with the zod repo by putting a bad assertion in one of the tests and observing that they continue to pass.
(FYI @colinhacks because of this zod might have a bunch of broken tests on the
v4
branch - that's where I found this, with vitest ^1.6.0, not sure about other branches)Note: with
"vitest": "latest"
the "Tests" still pass but there's an unhandled error with no extra info.System Info
System: OS: Linux 5.0 undefined CPU: (8) x64 Intel(R) Core(TM) i9-9880H CPU @ 2.30GHz Memory: 0 Bytes / 0 Bytes Shell: 1.0 - /bin/jsh Binaries: Node: 18.20.3 - /usr/local/bin/node Yarn: 1.22.19 - /usr/local/bin/yarn npm: 10.2.3 - /usr/local/bin/npm pnpm: 8.15.6 - /usr/local/bin/pnpm npmPackages: vitest: 2.0.3 => 2.0.3
Used Package Manager
npm
Validations
The text was updated successfully, but these errors were encountered: