Describe the bug
Use case
I'm building a Svelte 5 wrapper library for SAP UI5 Web Components (@ui5/webcomponents).
Each custom element (e.g. <ui5-button>) gets a generated Svelte wrapper so users get autocompletion and type safety.
<ui5-button> has a named slot badge that expects a <ui5-button-badge> element.
I also wrap <ui5-button-badge> in a Svelte component ButtonBadge.svelte.
The problem
When using <ButtonBadge slot="badge"> inside a {#snippet badge()} block, svelte-check reports a type error:
Error: '$$_nottuB0.$$slot_def' is of type 'unknown'. (js)
{#snippet badge()}
<ButtonBadge slot="badge"></ButtonBadge>
{/snippet}
====================================
svelte-check found 1 error and 0 warnings in 1 file
The code works correctly at runtime — this seems to be purely a type-checking issue.
Or maybe I am doing something wrong?
Analysis
svelte-check generates $$ComponentProps = Props & Record<string, unknown> for every component.
This causes $$ComponentProps['$$slot_def'] to resolve as unknown (because Record<string, unknown> maps all unknown keys to unknown).
When the LS sees , it checks $$slot_def on the component type and gets unknown → type error.
Note: slot is explicitly declared in Props as slot?: string — the error persists regardless.
Question
In this Web Component integration pattern, slot="badge" is a native HTML attribute for browser slot assignment — not a Svelte slot directive.
The intended DOM output is:
<ui5-button>
<ui5-button-badge slot="badge" text="3"></ui5-button-badge>
</ui5-button>
Is it expected that slot="..." on a Svelte 5 component triggers $$slot_def checking?
Or should slot declared as a typed prop (slot?: string) be treated as a regular prop — without triggering slot-directive type checking?
Reproduction
Minimal reproduction: https://github.com/ybbus/my-app
The .d.ts files in src/lib/ represent what svelte-package generates when building a Svelte component library for distribution.
Expected behaviour
Should work without any type errors when running svelte-check.
System Info
Environment
- Windows 11
- Svelte: 5.54.0
- svelte-check: 4.4.2
- @sveltejs/kit: 2.50.2
- Svelte VS Code extension: 109.14.2
- TypeScript: 5.9.3
Which package is the issue about?
svelte-check
Additional Information, eg. Screenshots
No response
Describe the bug
Use case
I'm building a Svelte 5 wrapper library for SAP UI5 Web Components (
@ui5/webcomponents).Each custom element (e.g.
<ui5-button>) gets a generated Svelte wrapper so users get autocompletion and type safety.<ui5-button>has a named slotbadgethat expects a<ui5-button-badge>element.I also wrap
<ui5-button-badge>in a Svelte componentButtonBadge.svelte.The problem
When using
<ButtonBadge slot="badge">inside a{#snippet badge()}block,svelte-checkreports a type error:The code works correctly at runtime — this seems to be purely a type-checking issue.
Or maybe I am doing something wrong?
Analysis
svelte-check generates $$ComponentProps = Props & Record<string, unknown> for every component.
This causes $$ComponentProps['$$slot_def'] to resolve as unknown (because Record<string, unknown> maps all unknown keys to unknown).
When the LS sees , it checks $$slot_def on the component type and gets unknown → type error.
Note: slot is explicitly declared in Props as slot?: string — the error persists regardless.
Question
In this Web Component integration pattern, slot="badge" is a native HTML attribute for browser slot assignment — not a Svelte slot directive.
The intended DOM output is:
Is it expected that slot="..." on a Svelte 5 component triggers $$slot_def checking?
Or should slot declared as a typed prop (slot?: string) be treated as a regular prop — without triggering slot-directive type checking?
Reproduction
Minimal reproduction: https://github.com/ybbus/my-app
The .d.ts files in src/lib/ represent what svelte-package generates when building a Svelte component library for distribution.
Expected behaviour
Should work without any type errors when running svelte-check.
System Info
Environment
Which package is the issue about?
svelte-check
Additional Information, eg. Screenshots
No response