fix: error at compile time on unsupported TypeScript language features

[Rich-Harris]

closes #11502. For now I've just done enums

Before submitting the PR, please make sure you do the following

• [x] It's really useful if your PR references an issue where it is discussed ahead of time. In many cases, features are absent for a reason. For large changes, please create an RFC: https://github.com/sveltejs/rfcs
• [x] Prefix your PR title with feat:, fix:, chore:, or docs:.
• [x] This message body should clearly illustrate what problems it solves.
• [ ] Ideally, include a test that fails without this PR but passes with it.

Tests and linting

• [x] Run the tests with pnpm test and lint the project with pnpm lint

[changeset-bot[bot]]

🦋 Changeset detected

Latest commit: 8f44b5833270a57cb826408656eeba3a172d2f8c

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 1 package

Name	Type
svelte	Patch

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

[Rich-Harris]

It seems that acorn-typescript doesn't parse ~~enums~~ using (we should probably open an issue), while acorn does parse decorators but esrap doesn't print them (we should probably open an issue).

What other language features do we need to consider?

[dummdidumm]

• constructor(private/public/protected x)
• namespace X { export function y() { ... } } (though it seems we don't strip namespaces that only consist of types currently, and neither do we strip declare module, nor declare const/function/etc, which we should)
• class X { accessor y = .. }
• using ... (because it's not stage 4 yet / not in acorn)

[Rich-Harris]

oh wait i mean using instead of enums above

[Rich-Harris]

Also I misspoke when I said Acorn parses decorators — it's actually acorn-typescript doing that.

There is an effort underway to add TS support to esrap, which would include decorators and everything else. If that landed, would it in fact make sense to just support the features in question?

[dummdidumm]

I mean theoretically yes, but it would certainly be a non-trivial effort. The transformations that TS does under the hood are somewhat involved (you can look at the JS output tab in their playground).

[Rich-Harris]

I'm not suggesting we transform TypeScript syntax, just that we understand it enough that it doesn't mess up the analysis, and then we emit TS rather than JS

[dummdidumm]

Oh so you're saying that whatever comes after Svelte has to then know "ok this is a typescript file now so I'm gonna transform it using esbuild/tsc/whatever"? @dominikg how would that impact the toolchain?

[dominikg]

allowing the svelte compiler to emit ts that then has to be postprocessed is going to create a lot of effort. even if it works in vite, what about all the other bundlers or even just our repl?

[Rich-Harris]

Unfortunately this is the kind of thing the bundler designers of the world didn't anticipate — everything is more or less based on file extensions, so you'd need to configure the downstream transformers to keep an eye out for .svelte files as well.

Have thought for a while that the ecosystem would be more robust if instead of just returning { code, map } we could return various well-known attributes like language/version/whatever, so that a TS plugin could say 'oh, this .potato file generated some TypeScript — guess I'm up'. Hindsight is 20/20.