Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

TS to JSDoc Conversion

github.com

Post reply on HN
Print view View original

61–70 of 163 posts

Re: TS to JSDoc Conversion

#61

Post by rich_harris »

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!

If you're rabidly anti-TypeScript and think that us doing this vindicates your position, I'm about to disappoint you. If you're rabidly pro-TypeScript and think we're a bunch of luddite numpties, I'm about to disappoint you as well.

Firstly: we are not abandoning type safety or anything daft like that — we're just moving type declarations from .ts files to .js files with JSDoc annotations. As a user of Svelte, this won'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're used to (typechecking, intellisense, inline documentation etc). Our commitment to TypeScript is stronger than ever (for an example of this, see https://svelte.dev/blog/zero-config-type-safety).

I _would_ say that this will result in no changes that are observable to users of the framework, but that's not quite true — it will result in smaller packages (no need to ship giant sourcemaps etc), and you'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'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'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.

So this will ultimately benefit our users and contributors. But it will also benefit _us_, since we'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't quite as nice as writing in TypeScript. It's a relatively small price to pay (though opinions on this do differ among the team - this is a regular source of lively debate).

We're doing this for practical reasons, not ideological ones — we've been building SvelteKit (as opposed to Svelte) this way for a long time and it's been miraculous for productivity.

Re: TS to JSDoc Conversion

#62

Post by rich_harris »

bilalq wrote: post #58

It's immediately clear from the very first few lines of the PR that they're sacrificing safety for this. Before: import { Node } from 'acorn'; import * as code_red from 'code-red'; export const parse = (source: string): Node => code_red.parse(source, { sourceType: 'module', ecmaVersion: 13, locations: true }); After: import * as code_red from 'code-red'; /** * @param {string} source * @returns {any} */ export const p…

You are making judgements based on a draft PR. There is a ton of work still to do.

Re: TS to JSDoc Conversion

#63

Post by paulddraper »

dobladov wrote: post #26

We do this at my current company for all projects, it does not mean you don't use typescript, you will still validate all your files with TS, but there's no build step, just a check. Very rarely we find a case that we can't cover with JSDoc annotations, and most of the time it means the code could be refactored to be simpler. I do this now for all my personal projects, in my opinion it's simpler, faster and closer to…

TS compiler should have an CLI option to compile without type checks.

TS features don't need types to produce output[1] and this is supported by the compiler; it just doesn't have a CLI option.

Compiling without types is supported the compiler itself (this is what Babel does).

[1] Except const enum and export *

Re: TS to JSDoc Conversion

#64

Post by hn_throwaway_99 »

_oyks wrote: post #25

For anyone who is still confused - they're still gonna be using TypeScript in that they will have a tsconfig.json, `allowJS: true, checkJS: true` but they are just writing the files in JS with JSDoc type annotations, they'll still have `.d.ts` files to allow TS developers to use it without issues. Is it contrarian - yes - is it insane - no, not really. Edit: the motivation seems to be to simplify processes - running…

> but they are just writing the files in JS with JSDoc type annotations

I think this is the critical piece not everyone understands. Under the covers, it's basically still Typescript (see https://www.typescriptlang.org/docs/handbook/intro-to-js-ts....). The major difference is that type information is specified in comments so that the source file is still valid JS and thus doesn't need a separate compilation step. There is not an exact parity between type info that can be specified with JSDoc and Typescript, but my understanding is that it's pretty close.

Any folks familiar with Flow (before Typescript essentially won out), Flow had something similar that was very nice, IMO better because it was the same Flow syntax, just wrapped in comments: https://flow.org/en/docs/types/comments/

Re: TS to JSDoc Conversion

#65

Post by rich_harris »

sdwvit wrote: post #48

JSDoc and Typescript don't have feature parity: OOP that works across files, generics, inline types, etc.

This is a non-issue in practice — complex types can be expressed in .d.ts files and imported. SvelteKit (not Svelte) has been doing this for a long time and it's fine.

Re: TS to JSDoc Conversion

#66

Post by herpdyderp »

makapuf wrote: post #40
dobladov wrote: post #26

We do this at my current company for all projects, it does not mean you don't use typescript, you will still validate all your files with TS, but there's no build step, just a check. Very rarely we find a case that we can't cover with JSDoc annotations, and most of the time it means the code could be refactored to be simpler. I do this now for all my personal projects, in my opinion it's simpler, faster and closer to…

This is great but -if I dare - wouldn't it be time to allow js to have type annotations [1] ? As in python, treat it as comments for now but with real syntax and let interesting dialects emerge from the consensus ? I like jsdoc but the syntax is urgh. [1] https://github.com/tc39/proposal-type-annotations

It will be impossibly exciting if that proposal happens. I hate build steps, one of the reasons I latched onto JS for my career, but TS is just so good that I had to go full blast with it after using it for the first time.

Re: TS to JSDoc Conversion

#67

Post by benmccann »

nickreese wrote: post #10

Used to be really active in the svelte community and developed my own framework that got broad use. Getting Svelte and TS working together was a constant battle. This is a good decision.

Svelte will still provide type definitions. We're working on Svelte 4 currently and are taking the opportunity to make a few small breaking changes to the type definitions for improved TypeScript support: https://github.com/sveltejs/svelte/blob/version-4/CHANGELOG....

We'll cut a preview release soon and would love help testing and feedback from folks that have given it a try.

Re: TS to JSDoc Conversion

#69

Post by skrebbel »

_oyks wrote: post #25

For anyone who is still confused - they're still gonna be using TypeScript in that they will have a tsconfig.json, `allowJS: true, checkJS: true` but they are just writing the files in JS with JSDoc type annotations, they'll still have `.d.ts` files to allow TS developers to use it without issues. Is it contrarian - yes - is it insane - no, not really. Edit: the motivation seems to be to simplify processes - running…

XNR looks nice! I’m impressed that it can be faster than esbuild-runner, is there a downside?

Re: TS to JSDoc Conversion

#70

Post by alerighi »

dobladov wrote: post #26

We do this at my current company for all projects, it does not mean you don't use typescript, you will still validate all your files with TS, but there's no build step, just a check. Very rarely we find a case that we can't cover with JSDoc annotations, and most of the time it means the code could be refactored to be simpler. I do this now for all my personal projects, in my opinion it's simpler, faster and closer to…

> Very rarely we find a case that we can't cover with JSDoc annotations, and most of the time it means the code could be refactored to be simpler.

Can with JSDoc define types? And can you define generic types? To me that is the real power of TypeScript, being able to type every object you use.

Post reply on HN