Live data from Hacker News

TS to JSDoc Conversion

github.com

131–140 of 163 posts

Re: TS to JSDoc Conversion

#131

The developers providing everyone with free tools are or course welcome to write those tools in whatever languages they want. But to me, the comment definitions are longer to type and more difficult to parse than inline type definitions. I would much rather use one of the quick TS compilers that don't actually type check when I want to make and test a small change to my source code. But to each their own!

If a person value- TypeScript's inline syntax so much that they disagree with the developers that build steps are a nuisance, then surely they can put in a build step for themselves—one that takes TypeScript syntax as input and then "compiles" it into the equivalent JSDoc so they're never forced to type out those long, long comments. (If this is disagreeable, then your position is a lot less consistent than you think.)

Re: TS to JSDoc Conversion

#132

Wouldn't it be nice if all runtimes and browsers had native support for TS and you could just skip the entire transpiling and source mapping step? Oh, well.

Or better yet WASM was a first class citizen and we could abandon JS once and for all.

Re: TS to JSDoc Conversion

#133

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…

I've been doing the same for years and I'm really happy with it.

But the one big annoyance is events - I've never found a satisfying way of writing a JSdoc that says what events a class emits, or what parameters the events have. Do you have a way of handling this?

Re: TS to JSDoc Conversion

#134
post #53

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 I regret every `infer` statement I've put in application code. Grug phrased this elegantly: https://grugbrain.dev/#grug-on-type-systems

I have never seen grug before. This is fantastic.

Re: TS to JSDoc Conversion

#135

Earlier quoted context omitted.

Type imports are the worst.

Do you mean native JSDoc namepaths like /** * @type {module:look/here~MyType} */ or TypeScript "JSDoc" imports like /** * @type {typeof import("./look/here").MyType} */ or both?

I meant star type imports or rather lack of it.

Re: TS to JSDoc Conversion

#136
post #53

Earlier quoted context omitted.

> Very rarely we find a case that we can't cover with JSDoc annotations I regret every `infer` statement I've put in application code. Grug phrased this elegantly: https://grugbrain.dev/#grug-on-type-systems

I have never seen grug before. This is fantastic.

Past elder council with many wise tells:

https://news.ycombinator.com/item?id=31840331

Re: TS to JSDoc Conversion

#137

Finally things are heading in the right direction. Can't wait for more to do this. Typescript might be good for some, but I'm glad to see the hype finally begin to fade, so the rest of up can breathe again.

The biggest hurdle to using TypeScript is the build step before it can actually be run. If the type annotation TC39 [0] comes to pass this would be largely taken care of; _hype_ waxes. (unfortunately the proposal has been stagnant for more than a year now)

A lot of the new frontend codebases involve a build step before running. For such codebases, TypeScript's build hurdle has already been overcome.

[0] https://github.com/tc39/proposal-type-annotations

Re: TS to JSDoc Conversion

#139

Earlier quoted context omitted.

I don't use Svelte, but I appreciate the principled approach and the clear explanation. I primarily coded in Python for 4 years. Then I founded a company that didn't need as much data science and my primary language switched to JavaScript (2 years) then TypeScript (4 years). Overall, I really like TypeScript. But I do absolutely miss being able to cmd + click into a function/class from an open source package and see…

What if TypeScript could compile to JS/JSDoc instead of source maps? I'm also not a fan of 'go to definition' bringing me to a dead end d.ts file, but also there has to be a better solution than verbosely JSDoc'ing all the things.

There was talk about introducing type syntax as valid but ignored in the JS language, making TS valid JS.

It would take forever to become mainstream but if node and major browsers started to support this tomorrow, along with ESM modules we could drop TS compilation and bundling entirely during development, safely publish npm packages as TS (even a bundled TS) and simplify tooling for monorepos, IDEs, etc.

Unfortunately that wouldn't solve dealing with templates like JSX/TSX or future language syntax/features.

https://devblogs.microsoft.com/typescript/a-proposal-for-typ...

Re: TS to JSDoc Conversion

#140

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…

How do you type class properties?

https://github.com/microsoft/TypeScript/issues/26811

Post reply on HN