Reconsidering TypeScript for Svelte Compiler Internals

[rebasecase]

Describe the problem

I would like to respectfully open a discussion regarding the possibility of moving the compiler and internal codebase back to TypeScript. I fully appreciate the rationale behind the initial decision to use JavaScript with JSDoc annotations, as articulated by Rich Harris: “We also eliminate an entire class of annoying papercuts that will be familiar to anyone who has worked with the uneven landscape of TypeScript tooling” (reddit.com). The concerns about tooling friction, dual compilation, and iteration speed were entirely valid at the time.

However, the development landscape has evolved significantly. Node 23.6 now allows TypeScript files to run natively, substantially reducing the historical overhead of compilation. Tooling has also improved, with solutions such as tsx providing near-instant feedback loops. Many of the previous bottlenecks around compile-then-run workflows are now largely obsolete.

At the same time, the developer ecosystem has shifted. More contributors today are TypeScript-native rather than relying on JavaScript with TypeScript adaptations. Reintroducing TypeScript internally could broaden the pool of potential maintainers, reduce onboarding friction, and enable the team to take advantage of modern TypeScript features and stricter typing guarantees without compromising speed or simplicity.

I raise this suggestion not out of criticism but from a place of genuine concern for the project’s long-term sustainability. JavaScript with JSDoc has served Svelte well, but revisiting TypeScript could provide stronger alignment with the wider TypeScript-first ecosystem, enhance maintainability, and potentially accelerate development velocity over time.

Would it be possible to have a careful and open discussion regarding the pros and cons of reconsidering TypeScript internally? A genuine debate could allow the team to weigh historical trade-offs against modern tooling and contributor trends, ultimately supporting the project’s longevity.

Thank you for considering this perspective and for your ongoing dedication to the project.

[7nik]

1. Svelte declares support of Node down to 18.0. So "the concerns about tooling friction, dual compilation, and iteration speed" are still valid.
2. TS is a superset of JS, so if a person knows TS, they know JS. Learning JSDocs takes an hour.
3. Rewriting the codebase from JS to TS requires plenty of resources, plus it breaks all the pending PRs, and this refactoring almost certainly will introduce new bugs.
4. It will be a breaking change.

advantage of modern TypeScript features and stricter typing guarantees without compromising speed or simplicity

Can you provide an example where the typing is not strict enough or slow?

[rebasecase]

@7nik

• Why is internal development be constrained by Node 18? According to the official lifecycle schedule, it is already past its Active LTS and its final security maintenance ends this quarter (https://endoflife.date/nodejs). Clinging to an EOL runtime for tooling decisions is a security risk.

• Your assertion that "if a person knows TS, they know JS" is a vast oversimplification, much like saying a C++ developer inherently knows C best practices. TypeScript provides essential guardrails and type safety that prevent common errors. Dismissing the significant developer friction of moving from a TS-first workflow to JSDoc as "learning it in an hour" minimizes the real-world impact on contributor enthusiasm and code quality.

• The team has already undertaken this exact kind of migration before when moving from TypeScript to JSDoc. The effort is a known quantity. Considering TS is a superset of JS, a gradual migration back should be even more straightforward by your admission.

• To be clear, nobody is suggesting this change should be introduced immediately; that would be incredibly disruptive. This is a proposal to start a strategic discussion for a future major version. Think of the monumental Python 2 to 3 transition -- it was planned and announced years in advance to allow the ecosystem to adapt. A decision like this needs to be made well in advance, not as a sudden refactor.

• How would an internal source code and tooling change, with no modifications to the public API or compiler output, be a breaking change for users?

Finally, I have to say that your snappy and immediately dismissive response to a carefully articulated proposal is disheartening. As a woman in tech, this kind of tone comes across as unwelcoming and unnecessarily adversarial - sadly not unfamiliar.

Thanks

[Ocean-OS]

• Why is internal development be constrained by Node 18? According to the official lifecycle schedule, it is already past its Active LTS and its final security maintenance ends this quarter (https://endoflife.date/nodejs). Clinging to an EOL runtime for tooling decisions is a security risk.

Not everyone will (or has the ability to) update to an LTS version of Node. Unlike some people, we aren't saying that we should be compatible with Node 4, we just want to maintain compatibility with recent-ish versions of Node.

• Your assertion that "if a person knows TS, they know JS" is a vast oversimplification, much like saying a C++ developer inherently knows C best practices. TypeScript provides essential guardrails and type safety that prevent common errors. Dismissing the significant developer friction of moving from a TS-first workflow to JSDoc as "learning it in an hour" minimizes the real-world impact on contributor enthusiasm and code quality.

Most TypeScript developers likely have some experience with JavaScript. TypeScript introduced itself as JavaScript with types; not something entirely different from JS.

• The team has already undertaken this exact kind of migration before when moving from TypeScript to JSDoc. The effort is a known quantity. Considering TS is a superset of JS, a gradual migration back should be even more straightforward by your admission.

The team has had a couple migrations. Svelte 1 and 2 were written in JS, Svelte 3 in TypeScript, and Svelte 4 in JS. I don't think we need yet another migration.

• How would an internal source code and tooling change, with no modifications to the public API or compiler output, be a breaking change for users?

I agree with you on this; Svelte 4's rewrite to JS was explicitly described as not being a breaking change.

I seriously don't see the need to migrate to TypeScript again. It complicates the build/development process, and while Node does support basic type annotation removal, it does not support additive features such as enums.

[7nik]

Why is internal development be constrained by Node 18?

Because the source is what is distributed, thus, currently, the node version limit is the same for both internals and for users. Rising it is a breaking change. And supporting Node 18 barely affects Svelte development. And there still are Node 20 and 22.

Your assertion that "if a person knows TS, they know JS" is a vast oversimplification, much like saying a C++ developer inherently knows C best practices. TypeScript provides essential guardrails and type safety that prevent common errors. Dismissing the significant developer friction of moving from a TS-first workflow to JSDoc as "learning it in an hour" minimizes the real-world impact on contributor enthusiasm and code quality.

C and C++ are different languages in many meanings, while TS is completely backward compatible with JS. JSDocs provides the same level of typesafety, though it is not so convenient in some cases.
Plus, here we do use some uncommon approaches (e.g. defining variables with var) for performance reasons, but new contributors don't have to know such things, as well as be a master of TS/JS - we always help to improve and polish PR.

How would an internal source code and tooling change, with no modifications to the public API or compiler output, be a breaking change for users?

You cannot guarantee that introducing a building step won't break somebody's tricky and edgy setup. Like currently you can import svelte src, though it is not an incorrect usage and unsupported case.

Finally, I have to say that your snappy and immediately dismissive response to a carefully articulated proposal is disheartening. As a woman in tech, this kind of tone comes across as unwelcoming and unnecessarily adversarial - sadly not unfamiliar.

It's a shame that you're faced with such things, but be assured, it's not the case here.
I'm not good at words, but my response is only oriented to your proposal.

I'd say that having a good contribution guide is more important than having the codebase in TS.

[Rich-Harris]

Let's assume good intent — English isn't everyone's first language.

tl;dr this isn't going to happen. We'd love to be able to author in TypeScript, but having a build-less workflow is much more important, and as long as we're forced to choose between them (which we are, since the alternative to building is to drop support for old Node, and that would obviously be a breaking change) we need to keep things as they are.

We could potentially revisit this when we release a major that drops support for old Node, though even then it would pose challenges (like running the compiler in the browser).

[Rich-Harris]

(note also that distributing .ts doesn't really work, since files in node_modules aren't transformed)

Node does not strip types in node_modules because it can cause significant performance issues for the official TypeScript compiler (tsc) and parts of VS Code, so the TypeScript maintainers would like to discourage people publishing raw TypeScript, at least for now.