Hacker News Reader

Comment by _oyks | Hacker News Reader

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 TS files can be awkward, and cross importing is awkward. fwiw created my own tool for this ([url-redacted])

View on HN

> 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/

TS can generate d.ts files from JS files that use JSDoc

ty, updated

I argue that it should support the other direction as well (.ts to .js with JSDoc instead of .ts to .js+.d.ts), but the TypeScript devs said they do not support that

It really doesn't look like that big of a change as well. Looking at the PR, they didn't go too heavy on their typescipt usage. I can see they when using typescript, they added types for function parameters, but not for return types, for example.

What is the reason behind choosing sucrase over swc?

FYI, you committed the wrong license file. The license file contains license text of a standard MIT License, but your project is licensed under Apache...

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

I know why it's fast (it doesn't do anything it doesn't need to), but not exactly sure why it's faster than esbuild-runner; presumably it had a higher latency when tested.

(and downsides not really, beyond it's pretty fresh so bug reports welcome)

Reply on news.ycombinator.com