Svelte 5: differentiate between supported and unsupported TypeScript features

[Rich-Harris]

Describe the problem

Svelte 5 supports TypeScript syntax natively, but it doesn't support TypeScript runtime features such as enums, using, decorators (related: #11397) and so on.

In general, a good piece of advice is 'don't use these features, they are a bad idea'. TypeScript isn't Babel — in 2024 it should be used for adding types, nothing more. But since not everyone is aware of this distinction or inclined to follow this advice, we need some way of handling these cases.

Describe the proposed solution

The compiler should error when encountering these features with a message that invites people to use the TypeScript preprocessor:

TypeScript decorators are a runtime feature that requires your code to be preprocessed before Svelte compiles it. See https://svelte.dev/docs/... for information on how to set up the preprocessor.

Not 100% sure what this would mean for TypeScript inside markup (or TypeScript that uses these features in .svelte.ts files, for that matter).

Importance

nice to have

[fcrozatier]

Also: ts auto accessor modifier (REPL)

[braebo]

don't use these features, they are a bad idea

These features are robust and widely used across the industry. Decorators are especially useful.

TypeScript isn't Babel

Why is it ok for Svelte to add features when compiling to javascript, but not Typescript?

[webJose]

I stumbled upon this issue after realizing my use of enum did not agree with the elimination of the Vite pre-processor. I too agree that it would be nice if all of TypeScript were supported. Having said that, if it cannot be had without the pre-processor, is not the end of the world, so long we can use said pre-processor. Thanks!

[fkrauthan]

same issue here in regards of enum in particular. It would be great if that could be support as it is quiet a useful feature (e.g. having a prop that is an enum that I want to define in my component rather then moving to a ts file).

[dummdidumm]

Errors for unsupported TypeScript features are thrown now. In the future we can look into supporting specific features. Enums for example are rather easy to transform, so we could do that.

[McGaelen]

Hi all, I found this issue while trying to figure out why my enums were causing issues after I updated to Svelte 5 - personally, I do think it's a little confusing to basically have 2 "levels" of typescript support (one where runtime features won't work, and another with vitePreprocess({script: true}) which returns things back to vanilla TS).

I think that Svelte should allow all Typescript features by default, regardless of viewpoint on runtime features. Googling for Typescript issues may give solutions that use these runtime features, only for a newbie to implement them in Svelte and be met with errors. Now, I realize that the goal is to make these errors easy to understand and fix (or workaround), but I still respectfully disagree with the overall direction.

If someone doesn't want to use runtime features, they can just choose not to use them, or maybe the default could be vitePreprocess({script: true }) and let people set it to false if they want. I'm just not a fan of "we support Typescript but only parts of it". It feels like Svelte takes an opinionated approach with this, which I don't think should be the default (not because I disagree with the sentiment around runtime features, but because it causes confusion.)

Thanks to all who have worked on Svelte[Kit] - it's an amazing framework that has served me well for years, and certainly many more.

[webJose]

@McGaelen my sentiment, exactly. Svelte should remain an unopinionated framework.

[Rich-Harris]

It's not a question of opinions. There are two TypeScripts — there's JavaScript+types, which Bloomberg refer to (correctly IMHO) as Modern TypeScript, and there's the stuff that affects behaviour at runtime. For historical reasons they're both 'TypeScript' but they're entirely different beasts.

[braebo]

While we can discuss the merits of different TypeScript runtime features (and likely agree on how bad they are), I agree that people should be free to use or avoid language features based on their needs rather than limitations of their frontend framework.

If Svelte wants to recommend against certain TypeScript features, that's fine - but semantically appropriating the word "TypeScript" itself to mean "a subset of Typescript that excludes those features" doesn't seem like the best way to do it, especially when thousands of companies / developers already use of them.

If we can only support a subset of TypeScript, our documentation should say that (and ideally explain why such a limitation exists), regardless of what TypeScript features we think people "should" use.