Skip to content
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

feat: better type checking for bindings in Svelte 5 #2477

Merged
merged 4 commits into from
Aug 28, 2024

Conversation

dummdidumm
Copy link
Member

@dummdidumm dummdidumm commented Aug 28, 2024

#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.

@dummdidumm dummdidumm merged commit 8c080cf into master Aug 28, 2024
3 checks passed
@dummdidumm dummdidumm deleted the binding-type-checks branch August 28, 2024 15:21
dummdidumm added a commit that referenced this pull request Sep 19, 2024
dummdidumm added a commit that referenced this pull request Sep 19, 2024
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.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant