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

Why is this line marked as error? #2556

Open
dm-de opened this issue Nov 2, 2024 · 8 comments
Open

Why is this line marked as error? #2556

dm-de opened this issue Nov 2, 2024 · 8 comments
Labels
bug Something isn't working Fixed Fixed in master branch. Pending production release.

Comments

@dm-de
Copy link

dm-de commented Nov 2, 2024

Describe the bug

<script>
	let { array = [] } = $props()
	let array2 = $derived(array.filter(i => !i.hidden))
</script>

In this short example, filter is marked red
'array' is of type 'unknown'.

For example, when I use next code in TS playground, it will not mark array or filter as error. Expected errors are $props() and i. But not arary or filter.

let { array = [] } = $props()
array.filter(i => !i.hidden) 

My configuration:
installed using Vite (fresh installation)
but not Svelte kit
just JS Svelte 5 (newest)
or even TS (no difference)
newest Svelte extension for VS code
newest VS Code update

Such error come up with Svelte 5 first (Svelte 4 show no errors).
I hoped all the time that this will be fixed with final v5.

I played with checkJS - or ts-nocheck.
But this will hide any error.

sv3

Reproduction

<script>
	let { array = [] } = $props()
	let array2 = $derived(array.filter(i => !i.hidden))
</script>

Expected behaviour

no error

System Info

  • OS: Windows
  • IDE: VSCode

Which package is the issue about?

Svelte for VS Code extension

Additional Information, eg. Screenshots

No response

@dm-de dm-de added the bug Something isn't working label Nov 2, 2024
@dummdidumm
Copy link
Member

You can't both strictly type check your code and expect no error in these positions. If you opt into more type checking, you have to provide the types, too. What we can do however is detect that you're creating an array-type fallback, and type that as unknown[].

@dm-de
Copy link
Author

dm-de commented Nov 11, 2024

is fixed now, but what can we do, to auto-remove such errors?

all properties of an array/object are unknown - but it is annoying
sv5

@dm-de
Copy link
Author

dm-de commented Nov 11, 2024

I found other issue. This is not fixed:

sv7

<script>
	let {
		children,
	} = $props()
</script>

<div>
	{@render children?.()}
</div>

In my eyes, this line should also be error-free:

{@render children()}

@dm-de
Copy link
Author

dm-de commented Nov 11, 2024

Here is another error. Possible same like previous.

sv6

I found one way to hide it with:
ontoggle = ()=>{},

Is it possible to make it error free without extra function?

@dm-de
Copy link
Author

dm-de commented Nov 11, 2024

another classic example with error:

sv8

@dm-de
Copy link
Author

dm-de commented Nov 11, 2024

Is it OK, to post more of this here? Or should I open a new issue?
Next one is different that others.

{disabled} is marked wrongly.
Happen only with checkbox and only if here is bind:checked

Type 'unknown' is not assignable to type 'boolean'

sv9

<script>
	let {
		disabled = false,
		value = $bindable(),
	} = $props()
</script>

<input
	type="checkbox"
	{disabled}
	bind:checked={value}
/>

@dm-de
Copy link
Author

dm-de commented Nov 11, 2024

One more - object prop types not recognized

Type 'unknown' is not assignable to type 'string'

sv10

Parent:

<script>
	import Text from './t.svelte'
	let {
		i18 = {ok: 'OK', yes: 'Yes', no: 'No'},
	} = $props()
</script>
	
<Text text={i18.ok} />

Child:

<script>
	let { text = '' } = $props()
</script>

{text}

@dm-de
Copy link
Author

dm-de commented Nov 11, 2024

one more with input FILE

Type '{}' is missing the following properties from type 'FileList': length, item,

sv11

<script>
	let {
		value = $bindable(),
	} = $props()
</script>


<input
	bind:files={value}
	type="file"
/>

dummdidumm added a commit that referenced this issue Nov 12, 2024
The idea was to be conservative about it, but this causes problems for people not wanting strict type checking but only a basic form of it. Falling back to `any` is the more pragmatic choice

#2556
dummdidumm added a commit that referenced this issue Nov 12, 2024
)

The idea was to be conservative about it, but this causes problems for people not wanting strict type checking but only a basic form of it. Falling back to `any` is the more pragmatic choice

#2556
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working Fixed Fixed in master branch. Pending production release.
Projects
None yet
Development

No branches or pull requests

2 participants