TS to JSDoc Conversion
Lordy, I did not expect an internal refactoring PR to end up #1 on Hacker News. Let me provide some context, since a lot of people make a lot of assumptions whenever this stuff comes up!<p>If you&#x27;re rabidly anti-TypeScript and think that us doing this vindicates your position, I&#x27;m about to disappoint you. If you&#x27;re rabidly pro-TypeScript and think we&#x27;re a bunch of luddite numpties, I&#x27;m about to disappoint you as well.<p>Firstly: we are not abandoning type safety or anything daft like that — we&#x27;re just moving type declarations from .ts files to .js files with JSDoc annotations. As a user of Svelte, this won&#x27;t affect your ability to use TypeScript with Svelte at all — functions exported from Svelte will still have all the same benefits of TypeScript that you&#x27;re used to (typechecking, intellisense, inline documentation etc). Our commitment to TypeScript is stronger than ever (for an example of this, see <a href="https:&#x2F;&#x2F;svelte.dev&#x2F;blog&#x2F;zero-config-type-safety" rel="nofollow">https:&#x2F;&#x2F;svelte.dev&#x2F;blog&#x2F;zero-config-type-safety</a>).<p>I _would_ say that this will result in no changes that are observable to users of the framework, but that&#x27;s not quite true — it will result in smaller packages (no need to ship giant sourcemaps etc), and you&#x27;ll be able to e.g. debug the framework by cmd-clicking on functions you import from `svelte` and its subpackages (instead of taking you to an unhelpful type declaration, it will take you to the actual source, which you&#x27;ll be able to edit right inside `node_modules` to see changes happen). I expect this to lower the bar to contributing to the framework quite substantially, since you&#x27;ll no longer need to a) figure out how to link the repo, b) run our build process in watch mode, and c) understand the mapping between source and dist code in order to see changes.<p>So this will ultimately benefit our users and contributors. But it will also benefit _us_, since we&#x27;re often testing changes to the source code against sandbox projects, and this workflow is drastically nicer than dealing with build steps. 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. The downside is that writing types in JSDoc isn&#x27;t quite as nice as writing in TypeScript. It&#x27;s a relatively small price to pay (though opinions on this do differ among the team - this is a regular source of lively debate).<p>We&#x27;re doing this for practical reasons, not ideological ones — we&#x27;ve been building SvelteKit (as opposed to Svelte) this way for a long time and it&#x27;s been miraculous for productivity.