Live data from Hacker News

TS to JSDoc Conversion

github.com

51–60 of 163 posts

Re: TS to JSDoc Conversion

#51
post #14

It always makes me chuckle when a bunch of non-contributors come out of the woodwork to provide their opinion on a change which will affect them not at all.

We also demand that they stop working on any web3 integrations because it’s useless and we dont like it

Re: TS to JSDoc Conversion

#52
We are (unfortunately) already doing just JSDoc.

Typescript migration was on our road map, but when we dug into it, it didn't solve the biggest issue we had with Javascript, which forces the developer to be aware of various pitfalls. Because of that, we didn't feel that TypeScript solved enough of JavaScript's faults to warrant a migration.

I still think that TypeScript is great and has some of the best tooling I've had the pleasure of working with, but in our case we didn't feel that the added complexity was worth the trade off. JSDoc is "good enough", even though we've run into bugs with it on VS Code.

Re: TS to JSDoc Conversion

#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

Re: TS to JSDoc Conversion

#54
post #19

If I remember right, symfony (php framework) has comments that affect how the code runs which as far as I’m concerned means they’re not comments at all but actually code masquerading as comments. Reading about JSDoc gives me the same uneasy feeling, even if it’s not quite the same thing. Edit: Here’s one example, you can define your routes in symfony using comments. Not only that, but it’s actually the officially rec…

> as I’m concerned means they’re not comments at all Smuggling pragmas in comment has a long and rich history. It’s literally the reason why json does not support comments. > Reading about JSDoc gives me the same uneasy feeling, even if it’s not quite the same thing. It’s not just “not quite the same thing”, it’s entirely unrelated in every way and shape. JSDoc does not affect the runtime behaviour of its code, or ho…

> JSDoc does not affect the runtime behaviour of its code, or how that code interacts with other systems.

At the moment. You’ve literally just said yourself that there is a long history of smuggling code into comments. A few years down the line I don’t want to suddenly have the feature added and then have to be on the look out when I’m debugging a codebase for secret code in comments.

Re: TS to JSDoc Conversion

#55
post #52

We are (unfortunately) already doing just JSDoc. Typescript migration was on our road map, but when we dug into it, it didn't solve the biggest issue we had with Javascript, which forces the developer to be aware of various pitfalls. Because of that, we didn't feel that TypeScript solved enough of JavaScript's faults to warrant a migration. I still think that TypeScript is great and has some of the best tooling I've…

What kind of pitfalls are you talking about?

Re: TS to JSDoc Conversion

#56
post #14

It always makes me chuckle when a bunch of non-contributors come out of the woodwork to provide their opinion on a change which will affect them not at all.

I think the reason is that the change just sounds so insane at face value that many can't help but comment on it.

Re: TS to JSDoc Conversion

#57
Sveltekit, back to server side rendering.

Documentation, with JSDoc back to good old comment/type documentation.

Can't wait to see what clock we set the time back at next.

Re: TS to JSDoc Conversion

#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 parse = (source) =>
      code_red.parse(source, {
        sourceType: 'module',
        ecmaVersion: 13,
        locations: true
      });

But I'm not a Svelte maintainer or user, so if this is their choice, I guess it is what it is. It's not something I'd ever consider. There are other approaches for making linked npm package workflows more manageable. There's the one mentioned by one of the VSCode maintainer, but the simplest setup is to just have a watch process running that recompiles on the fly.

Re: TS to JSDoc Conversion

#59
post #50
post #14

It always makes me chuckle when a bunch of non-contributors come out of the woodwork to provide their opinion on a change which will affect them not at all.

Funnily enough it's always stuff that's bikesheddding. I spend months trying to solicit feedback on new experimental stremaing/cancellation APIs in Node and it's silence for a year until people start using it. We say that contributors agreed to list pronouns in the readme or we mention inclusivity and oh-boy do a lot of random people from the internet cares about how the volunteers that write the software they use fo…

> oh-boy do a lot of random people from the internet cares about how the volunteers that write the software they use for free refer to each other internally

Oh boy. If they don't like it, then they don't have to contribute. (Spoiler: none of them are contributing anything.)

Post reply on HN