search

sveltejs / language-tools

The Svelte Language Server, and official extensions which use it
MIT License
1.25k stars 199 forks source link

Intermediate type hides errors with component doesn't implement $$Props #1830

Open kizivat opened 1 year ago

kizivat commented 1 year ago

Describe the bug

I cannot pinpoint what causes this exactly, but when I was trying to implement prop types that are inferred from the value of another one, I ran into a weird issue - weir because it's solved when I create an intermediate type to assign a intersection type to $$Props

type T = $$Generic<SupportedAs>;
+ type Props = RenderProps<T> & { anotherProp: string };
- type $$Props = RenderProps<T> & { anotherProp: string }; // error
+ type $$Props = Props;

While I was trying to create an example I discovered another error which just pretends like a type defined just previous line cannot by found.

You can find both examples in repo: https://github.com/kizivat/svelte-props-error

The original problem can be seen in file https://github.com/kizivat/svelte-props-error/blob/main/src/lib/components/WithoutIntermediateType.svelte while in https://github.com/kizivat/svelte-props-error/blob/main/src/lib/components/IntermediateType.svelte is the solution to the problem.

The second problem I've discovered along the way (not sure if connected) can be seen at https://github.com/kizivat/svelte-props-error/blob/main/src/lib/components/SupportedElementError.svelte

Reproduction

git clone https://github.com/kizivat/svelte-props-error
npm i

Expected behaviour

I would expect bot erroneous cases to work without errors. 🤔

System Info

Which package is the issue about?

None

Additional Information, eg. Screenshots

No response

jasonlyu123 commented 1 year ago

It should be the opposite. The error is presented in both cases. It just got filtered out during our internal source mapping. I am not sure if there is a way to achieve what you want with $$restProps. Having a union type depending on another variable rarely works. but it should work if you use $$props.

The second one is a separate issue. Some of the types related to generic are hoisted to module scope in our internal transformation. So it should work if you put the type in <script context="module"> The reason is that the type is referenced in the generic so it should be in the same scope as the generic function instead of inside it. In your case, the type also references a local variable. I am not sure we want to allow this kind of usage. I think we should just show an error suggesting moving it to <script context="module"> or another file