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

111–120 of 163 posts

Re: TS to JSDoc Conversion

#111

Post by PaulMest »

rich_harris wrote: post #61

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.…

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 the actual implementation and not just a type definition. This is probably the biggest day-to-day frustration I have with TS compared to JS and Python.

Re: TS to JSDoc Conversion

#112

Post by mxkyb »

alerighi wrote: post #70
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.

and you can always define more complex types in interfaces and import into jsdoc.

Re: TS to JSDoc Conversion

#113

Post by rich_harris »

zdragnar wrote: post #91
rich_harris wrote: post #65

Earlier quoted context omitted.

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.

I wish this were true. I'm currently dealing with three third-party libraries whose types are out of date with the actual code because they do this.

If those libraries were set up correctly, this would cause typechecking to fail.

Re: TS to JSDoc Conversion

#114

Post by dTP90pN »

mirekrusin wrote: post #24
lucasyvas wrote: post #15

Isn't casting with JSDoc impossibly ugly though? The inputs/outputs of a function signature are not the only times a type annotation is needed in TS.

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?

Re: TS to JSDoc Conversion

#115

Post by sanitycheck »

givemeethekeys wrote: post #17

A bit off-topic (sorry): Is anyone using Svelte in production without SvelteKit? Hows Svelte documentation as of late?

Yes, because Kit won't work on my target platforms.

They've been focusing on SvelteKit, so plain Svelte has stayed pretty much the same for a while. It's nice, stable, feels finished. I'm ever so slightly afraid of what could happen now attention appears to be on it again.

The docs + tutorial are very good, even approaching "fun" (YMMV).

Re: TS to JSDoc Conversion

#116

Post by mdaniel »

mjjp wrote: post #98
alerighi wrote: post #70

Earlier quoted context omitted.

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

Yes you can with @typedef and @template

for those interested, https://jsdoc.app/tags-template.html is 404 but https://github.com/google/closure-compiler/wiki/Generic-Type... appears to be the thing (reinforcing my rage at the JFC situation with JSDoc specification)

Re: TS to JSDoc Conversion

#117

Post by deprecative »

_gruntled wrote: post #110
preommr wrote: post #100

Earlier quoted context omitted.

> 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! Because people want to follow in the footsteps of big projects that have gained specialized knowledge through experience. It's also a really contrarian viewpoint about typescript which is really popular. tbh, this seems pretty far…

> It's also a really contrarian viewpoint about typescript which is really popular. I really, really don't get the controversy here. JSDoc _is_ TypeScript, just with a syntax that's valid JavaScript (on account of it living in comments). This means it doesn't have to be built to run, but still gets all of the typing goodies regular TypeScript does. The end-user code authoring experience is the same or better. > To co…

> "It's regressive to use a fully-JS TypeScript syntax instead of using dozens of tools on top of regular TypeScript to achieve the same outcome" is quite a spicy take.

To be fair, "We are so invested in TypeScript we're dropping it!" is an equally astonishing take. It's language I'd expect from Google about any of their projects.

Re: TS to JSDoc Conversion

#118

Post by _gruntled »

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…

We're using an automated tool to do the gross conversion, then combing through fixing the issues. There's a reason the PR's a draft, dammit! :lol: Don't worry, _no_ type-safety will be lost, internally or externally.

Re: TS to JSDoc Conversion

#119

Post by bottlepalm »

PaulMest wrote: post #111
rich_harris wrote: post #61

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.…

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.
Post reply on HN