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

71–80 of 163 posts

Re: TS to JSDoc Conversion

#71

Post by rcarr »

jjice wrote: post #39
leoedin wrote: post #32

Earlier quoted context omitted.

Are they not using attributes, which start with a #? I thought PHP had C style // comments.

They are attributes. PHP does also allow # as a comment character in addition to // style comments and I assume that's where the poster got confused.

You can call it an “attribute” and you can also call it a “comment that affects the code” - they’re both just labels for the same thing. If you don’t want the latter to be a legitimate label (and it is, because I’ve communicated that idea with those words and you’ve understood what I’m referring to immediately) then the solution is to use any other symbol other than those reserved for comments. Imagine if we just had something like const a = 2 * 3 *[pineapples] * 10 and pineapples was coloured in like a variable in your syntax highlighting and people were like oh yeah don’t worry about that, that’s just a comment in the middle of the arithmetic. It’s ludicrous.

Re: TS to JSDoc Conversion

#72

Post by bilalq »

rich_harris wrote: post #62
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.

Fair enough! I'd love to read a blog post about this after you finish the work.

EDIT: It'd be a great outcome in the end if this conversion spurs DX improvements in Node/TS.

Re: TS to JSDoc Conversion

#73

Post by [deleted] »

nepeckman wrote: post #45

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!

[deleted]

Re: TS to JSDoc Conversion

#74

Post by rkeene2 »

echeese wrote: post #29
_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…

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

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

Re: TS to JSDoc Conversion

#75

Post by apocalyptic0n3 »

rcarr wrote: 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…

JSDoc's PHP equivalent is phpDoc. It's just a way to document things and both are third party libraries that have industry-wide adoption.

What you're thinking of in PHP is not a comment. It's called an Attribute, is built into PHP itself, and while it does use a comment-syntax, it's the old style that is largely unused today ("#" at the start of a line). https://www.php.net/manual/en/language.attributes.overview.p...

JSDoc isn't similar at all, unless you build a compiler that does different things based on your JSDocs.

Re: TS to JSDoc Conversion

#76

Post by maxloh »

rcme wrote: post #3
antoineMoPa wrote: post #2

Why would anyone do this?

> As a Svelte compiler developer, debugging without a build step greatly simplifies compiler development. Previously, debugging was complicated by the fact that we had to debug using the build step. In addition, using JSDoc does not affect compiler’s development safety because the type is almost equivalent to TS. > Of course, Svelte developers (not compiler developers) will still be provided type definition files as…

Why don't them just use `tsc --watch`?

Re: TS to JSDoc Conversion

#77

Post by wirahx »

givemeethekeys wrote: post #17

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

Yep, but slowly converting it all over to SvelteKit. Saves me having to maintain servers, watch setups, build processes, deployment processes, routing, bundling, and so on.

Re: TS to JSDoc Conversion

#78

Post by Rapzid »

rich_harris wrote: post #62
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.

> There is a ton of work still to do.

What's the estimated ROI?

Re: TS to JSDoc Conversion

#79

Post by paiari »

rcarr wrote: post #8
yid wrote: post #5

Earlier quoted context omitted.

ts-node [1]: am i a joke to you? [1] https://www.npmjs.com/package/ts-node

I’ve generally found tsx to be better/less hassle than ts-node https://github.com/esbuild-kit/tsx

Great recommendation!

I gave tsx a test and found it has a 3x slower boot than my favorite one, tsm[0] (and this is using the native binary at "./node_modules/bin/tsx").

Unfortunately, tsm has much lower download numbers compared to tsx, so I can already see me jumping ship to it due to traction.

I usually install tsm locally with "--save-dev" and use "node -r tsm --enable-source-maps .ts" to run what I want. Here on a M1 Pro 32GB the difference between both is 0.17s for tsx and 0.06s for tsm.

I urge anyone that haven't tried yet to give tsm a chance. It works great with PM2 if you create a file like "server.pm2.js" and just add at the top of it "require('tsm')" followed by "require('server.ts')".

[0] https://www.npmjs.com/package/tsm

Re: TS to JSDoc Conversion

#80

Post by philo23 »

rcarr wrote: 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…

Originally Symfony did use comments (docblock style ones like: /* @Route ... */) for this kind of thing, but since PHP 8 they've moved towards using attributes [1]. The syntax of the attributes #[Route(...)] might look like a comment, but they are actually just valid bits of code you can pragmatically inspect through reflection [2] and then choose to run if you want.

Docblock comments can also be inspected with reflection [3] but have a much looser syntax, so it was up to you to parse them. Where as you can create a new instance of an attribute directly from the reflection object [4]

In your example Symfony uses it to build up the list of HTTP routes by looking through all your controllers for #[Route] attributes. Generally that's done once and then cached, at least in production.

Personally I try to avoid using them, but they're definitely not comments. More like metadata you can attach to classes/methods/properties/parameters then use however you want.

[1]: https://www.php.net/manual/en/language.attributes.syntax.php

[2]: https://www.php.net/manual/en/reflectionclass.getattributes....

[3]: https://www.php.net/manual/en/reflectionclass.getdoccomment....

[4]: https://www.php.net/manual/en/reflectionattribute.newinstanc...

Post reply on HN