test(svelte-query/{queryOptions,infiniteQueryOptions}): add 'eslint-disable' for 'vitest/expect-expect'#9496
Conversation
…isable' for 'vitest/expect-expect'
|
View your CI Pipeline Execution ↗ for commit a8cd517
☁️ Nx Cloud last updated this comment at |
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## main #9496 +/- ##
===========================================
+ Coverage 45.11% 89.20% +44.09%
===========================================
Files 208 18 -190
Lines 8319 176 -8143
Branches 1879 31 -1848
===========================================
- Hits 3753 157 -3596
+ Misses 4119 18 -4101
+ Partials 447 1 -446
🚀 New features to boost your workflow:
|
| import type { InfiniteData } from '@tanstack/query-core' | ||
|
|
||
| describe('queryOptions', () => { | ||
| // eslint-disable-next-line vitest/expect-expect |
There was a problem hiding this comment.
assertType of vitest could be better for this case
Could you check that?
There was a problem hiding this comment.
test('Should not allow excess properties', () => {
const options = infiniteQueryOptions({
queryKey: ['key'],
queryFn: () => Promise.resolve('data'),
getNextPageParam: () => 1,
initialPageParam: 1,
// @ts-expect-error this is a good error, because stallTime does not exist!
stallTime: 1000,
})
expectTypeOf(options).toEqualTypeOf<
CreateInfiniteQueryOptions<
string,
Error,
InfiniteData<string, unknown>,
Array<string>,
number
>
>()
})How about this?
There was a problem hiding this comment.
@mmkal (expect-type member) @sheremet-va @antfu (vitest member)
I used to think assertType in vitest was the best way to type test for cases like this, but I'm not entirely sure now. What is the best way to handle vitest/expect-expect when testing for these ts-expect-errors with vitest eslint? Could you share your thoughts?
There was a problem hiding this comment.
You could do something like
expectTypeOf(infiniteQueryOptions).toBeCallableWith({
queryKey: ['foo'],
...
})Which I believe vitest/expect-expect will allow, and it's pretty clear what the purpose of the test is that way too.
If that's still a linter error, I believe the expect-expect rule can be configured to allow expectTypeOf - although this would be worth allowing by default in vitest since it's built-in.
There was a problem hiding this comment.
Thanks for sharing your thought! I will try it❤️
There was a problem hiding this comment.
@mmkal I tried toBeCallable but it seems like expectTypeOf().toBeCallableWith isn't always doing what I'd expect compared to just calling the function directly 🥲
Could this be a bug in expect-type, or is it just a TypeScript limitation?
Aug-02-2025.01-20-16.mp4
There was a problem hiding this comment.
Ah, yes, it's using extends so won't do the excess property check - and yes that's a typescript limitation that probably can't be worked around in expect-type.
You can still have the test for the excess property if you go more explicit:
expectTypeOf(infiniteQueryOptions).toBeCallableWith({
queryKey: ['key'],
queryFn: () => Promise.resolve('data'),
getNextPageParam: () => 1,
initialPageParam: 1,
})
expectTypeOf(infiniteQueryOptions).parameter(0).not.toHaveProperty('stallTime')That second assertion does what you're looking for - if the function parameter allowed [key: string]: unknown it would fail. But understandable if you don't want to go so all-in on expect-type in this change.
…Options-add-eslint-disable-vitest-expect-expect
lachlancollins
force-pushed
the
main
branch
from
5d7869e to
18a12ca
Compare
|
Hey! Heads up — #10355 ( With the oxlint integration, I'd recommend closing this in favor of #10355 once it's merged. |
|
thanks, we’ll likely go ahead with #10355 so going to close this. |
5 participants
No description provided.