-
-
Notifications
You must be signed in to change notification settings - Fork 202
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
Better type safety for two way binding #1392
Comments
This works as expected. |
Ah wait, do you mean that, because it's a binding, this should check both ways, i.e. that |
Yes. Even though we define |
Implementation notes:
|
Will this still be a problem with Svelte 5? It's a bit dangerously to have the type checker being fine and then .... bam! ... Things break. 😬 |
#1392 This adds enhanced type checking for bindings in Svelte 5: We're not only passing the variable in, we're also assigning the value of the component property back to the variable. That way, we can catch type errors like the child binding having a wider type as the input we give it. It's done for Svelte 5 only because it's a) easier there b) doesn't break as much code (people who upgrade can then also upgrade the types, or use type assertions in the template, which is only possible in Svelte 5). There's one limitation: Because of how the transformation works, we cannot infer generics. In other words, we will not catch type errors for bindings that rely on a generic type. The combination of generics + bindings is probably rare enough that this is okay, and we can revisit this later to try to find a way to make it work, if it comes up. Also note that this does not affect DOM element bindings like <input bind:value={...} />, this is only about component bindings.
Yeah, it's annoying but really helpful because I had hundreds of possible errors that I'm fixing right now thanks to svelte-check@4. |
Out of curiosity, since you said "hundreds of possible errors" - can you give an example of one such error? Hundreds sounds a bit much, so I just want to make sure that we didn't accidentally create false positives. |
Not at all. My code was the problem. Hundreds because my errors were in many components. 90% the The |
This reverts commit 8c080cf. This reverts #2477. Sadly, the idea didn't work out, as shown by two opened bug reports: - #2506: A type union can be narrowed on the input, but not on the way back out - #2494: A generic nested within a bound value is not properly resolved and not falling back to `any` (in #2477 we thought of the generic case, but only for when the generic is the whole value type, not when it's nested) For these reasons I don't see a way to properly implement #1392 at the moment.
I don't see #2477 as reverted |
It's merged it's just pending a release @Malix-Labs |
Describe the bug
There's no
svelte-check
error when binding to a property if the property is a broader type.To Reproduce
MyComponent.svelte:
Expected behavior
There should be a type error because
value
is defined asDate
even though it can also benull
System
svelte-check
,svelte2tsx
The text was updated successfully, but these errors were encountered: