Props type inference in Svelte 5: infer most, specify some?

[th0rgall]

Hello, I'm doing a sizeable Svelte 4 -> 5 migration, and I've encountered some components which have many props with default values.

In Svelte 4, Svelte/TS could infer the types of the props using their default values. For those props that did not have a default value, it was possible to explicitly specify their type while keeping inference for the rest.

I haven't found a way to do this in Svelte 5 without explicitly specifying the type for each property. Am I missing something?

Here's an excerpt from the codebase with a few default values:

Svelte 4:

  export let accept: string | string[]; // <-- notice this is the only prop with a specific type definition
  export let disabled = false;
  export let maxSize = Infinity;
  export let minSize = 0;
  export let multiple = true;

In Svelte 5, two changes are needed, as far as I could find:

1. Every property has to be explicitly specified in a separate type definition.
2. Every property which has a default ("fallback") now needs to be made optional, otherwise the component user still has to provide it.

  type Props = {
    accept: string | string[];
    disabled: boolean;
    maxSize?: number;
    minSize?: number;
    multiple?: boolean;
  };

  let {
    accept,
    disabled = false,
    maxSize = Infinity,
    minSize = 0,
    multiple = true,
  }: Props = $props();

What doesn't work:

  // Svelte 5: if we try to specify a type only for `accept`, we get errors like:
  //  > Property '.......' does not exist on type '$$ComponentProps'.
  let {
  .... props with default values....
  }: { accept: string | string[] } = $props();

Is the conclusion that Svelte 5 is just unavoidably more verbose in this situation?

[krishkhinchi]

Hii @th0rgall,

In Svelte 5, to mix inferred defaults with explicit types, use Partial or optional props:

interface ExplicitProps { accept: string | string[] }

let {
  accept,
  disabled = false,
  maxSize = Infinity,
  minSize = 0,
  multiple = true,
  preventDropOnDocument = true,
  noClick = false,
  noKeyboard = false,
  noDrag = false,
  noDragEventsBubbling = false,
  containerClasses = '',
  containerStyles = '',
  disableDefaultStyles = false,
  name = ''
}: Partial<ExplicitProps> & typeof $props() = $props();

• Partial<ExplicitProps> → types only required props (accept).
• typeof $props() → keeps inference for defaults.

✅ Rule of thumb: use explicit types for required props, defaults handle inference for the rest.

---

If this answer solved all your doubts, please mark it as solved. If not, please tell me your doubt.

[th0rgall]

Thanks for trying to help, but did you check this answer in practice? This doesn't have any effect. Partial makes props optional, and accept is the only one we don't want to have optional. Moreover, typeof $props() isn't even valid TypeScript, let alone that it would do some weird recursion if it worked. typeof docs state you can only use typeof on identifiers, not on function call expressions.

Honestly, this smells like an AI answer. You have to verify those, always.

[sunnypatell]

@th0rgall yes, svelte 5 is unavoidably more verbose here. this is a known trade-off of the runes design and it's working as intended.

why it works this way: in svelte 4, each export let was its own declaration so typescript could infer types per-variable. in svelte 5, $props() merges everything into a single destructuring assignment, and typescript has no syntax for "infer some properties, explicitly type others" in a destructuring pattern. this is actually a long-standing typescript limitation (156+ comments, still open).

when you write }: { accept: string | string[] } = $props(), typescript treats that as the complete type of the object, so disabled, maxSize etc. don't exist on it.

a few things that were considered and rejected:

• $props<T>() generic syntax existed briefly but was removed in next.79 because defaults created bad unions ($props<{a: number}>() with a = '' gave string | number)
• singular $prop rune was proposed (140 upvotes) but closed as not planned since it couldn't handle rest props, $bindable(), or reserved keywords like class

the cleanest pattern for your case:

interface Props {
  accept: string | string[];
  disabled?: boolean;
  maxSize?: number;
  minSize?: number;
  multiple?: boolean;
}

let {
  accept,
  disabled = false,
  maxSize = Infinity,
  minSize = 0,
  multiple = true,
}: Props = $props();

for components with many optional props that share patterns, you can use intersection types to reduce repetition:

type Validatable = { maxSize?: number; minSize?: number };
type Props = Validatable & {
  accept: string | string[];
  disabled?: boolean;
  multiple?: boolean;
};

ref: svelte $props docs | discussion #10690 (brunnerh's explanation) | TS #29526 (partial destructuring types)

[DucMinhNe]

Short answer: no — under $props() you can't keep inference for some props while explicitly typing others; you have to declare the type for the whole object. This isn't really a Svelte limitation, it's a TypeScript one: a destructuring annotation describes the entire pattern, so }: { accept: string | string[] } = $props() makes disabled, maxSize, etc. unknown. TS has no "annotate some keys, infer the rest" syntax for destructuring patterns (the closest open proposal is just about making annotations on binding patterns less verbose — microsoft/TypeScript#29526).

What you can do is reduce the boilerplate, not eliminate it. Since every prop with a fallback should be optional anyway, mark those ? and only the no-default props stay required:

interface Props {
  accept: string | string[];   // required, no default
  disabled?: boolean;
  maxSize?: number;
  minSize?: number;
  multiple?: boolean;
}

let {
  accept,
  disabled = false,
  maxSize = Infinity,
  minSize = 0,
  multiple = true,
}: Props = $props();

A couple of notes:

• The ? is what restores the Svelte 4 behavior where defaulted props were optional for the consumer — without it the prop stays required even though you gave it a fallback.
• If you have groups of optional props shared across components, factor them into a reusable type and intersect: type Props = CommonOptional & { accept: string | string[] }. That trims repetition without losing the explicit types.

The previously suggested Partial<...> & typeof $props() doesn't work: Partial would make accept optional too (the one prop you want required), and typeof $props() isn't valid TS — typeof operates on identifiers/qualified names, not call expressions.

So for this case Svelte 5 is a bit more verbose by design — explicit annotation on the full $props() destructure is the only supported approach ($props docs).

[Kasra-G]

Since everyone is giving AI answers I figured I could give a genuine one.

I think the workaround you mentioned is what you need to do. Personally I think it only makes your component inputs clearer when you explicitly state the props as an interface. So unless typescript has an update, or svelte some day allows you to call the $props() rune multiple times, like this:

let { required }: {required: boolean} = $props()

let { optionalA = true, optionalB = "boba"} = $props()

you'll probably have to explicitly type your optional fields