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

121–130 of 163 posts

Re: TS to JSDoc Conversion

#121

Post by bilalq »

_gruntled wrote: post #118
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.

Fair enough. Minor nit, the PR is not actually marked as a draft.

Re: TS to JSDoc Conversion

#122

Post by _gruntled »

deprecative wrote: post #117
_gruntled wrote: post #110

Earlier quoted context omitted.

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

But that's the thing, it's _not astonishing_. It _would_ be astonishing if we were abandoning typing Svelte. We're not. We're not even abandoning TypeScript -- the whole project will still run `tsc` and enforce complete type-safety, it just won't use the compiled output. This is _abandoning one syntax for another_ because one syntax doesn't require a build step and a huge toolchain to run and debug.

Re: TS to JSDoc Conversion

#123

Post by Spivak »

hn_throwaway_99 wrote: post #95
Zamicol wrote: post #86

Earlier quoted context omitted.

Digs through some of my Javascript Twitter rants The latest I ran into, `Object.keys(x).length` appears to recalculate length on every call. There doesn't appear to be a fast (and idiomatic) way to get top level object size in Javascript without using a secondary incrementor.

This seems like a very odd example in many ways: 1. How on Earth would you expect a type validation library to assist with this example? 2. Looking at that example, I would expect that of course it would need to do work on every call. That is, Object.keys(x) is a function call that takes an object and returns a newly constructed array. So I'm not exactly sure what you would expect to be optimized here. I guess what y…

I think the argument is that JSDoc already gives them type validation. If you're going to go the effort of porting to a completely different language and add a compilation step that new language better provide some benefits beyond types like papering over warts like Kotlin does.

Re: TS to JSDoc Conversion

#124

Post by eyelidlessness »

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 casting (type assertion, in TS parlance) is incredibly annoying to do in JS/JSDoc. In an ideal world, that would be a distinct advantage because type assertions are typically, or at least should be, considered risky: it’s a brute force way to ignore type errors. In the real world, you might find you have to correct inferred types, sometimes because they’re naively wide (eg, so many DOM interfaces devolve from HTMLElement to Element for no obvious reason!), but also often because they’re overly narrow (eg, so many dynamic collection member accesses completely ignore null safety, again for no obvious reason).

In practice, what I’ve found is that the hassle of adding type assertions even if they’re correct nudges me to write worse code (“to appease the type checker”) in JS/Doc than it does in TypeScript syntax. I don’t think TypeScript syntax makes me feel more relaxed about writing unsafe type assertions, but I’m probably an outlier because I pretty much only do that when I’ve exhausted every other available/known approach.

Re: TS to JSDoc Conversion

#126

Post by eyelidlessness »

rich_harris wrote: post #65
sdwvit wrote: post #48

JSDoc and Typescript don't have feature parity: OOP that works across files, generics, inline types, etc.

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.

It’s usually a non issue for most normal use cases. Some exceptions are truly maddening though, if you have good reason to use them. One off the top of my head that personally peeved me enough to ragequit one of my side projects: you cannot, as far as I’m aware, define an interface and assign its type to a class (neither its static constructor nor its instance members), without redeclaring every single member type in JSDoc. You can’t (again as far as I’m aware) even define types adjacent to their project-local implementation module and treat them the same way as @types/typeRoots. Both of these would be solvable if you could without polluting global scope, but again that’s a behavior only (again as far as I’m aware) available to dependencies.

I’d be thrilled to make the concession to a TypeScript flavor of header/implementation file pairs and skip a build step for huge portions of my work. But I spent way too long trying to figure out how to do it and my only remaining hope that it’s even possible is to wait for the “you don’t know?!” replies. (If it’s not clear here, they’d be very very welcome!)

Re: TS to JSDoc Conversion

#127

Post by nerdywordy »

TehShrike wrote: post #104
arzke wrote: post #90

Earlier quoted context omitted.

Is there any reason you wouldn't want to use SvelteKit now that is has reached version 1.0?

The business apps I work on don't benefit from SSR (having to write components that can render server-side is friction without payoff), and I already have a client-side router that supports nesting.

What router are you using? One in the svelte ecosystem or a vanilla js router?

Also in the process of writing an app that has no ssr needs. There are some minor annoyances with SvelteKit and interested in other options.

Re: TS to JSDoc Conversion

#128

Post by jjice »

rcarr wrote: post #71
jjice wrote: post #39

Earlier quoted context omitted.

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…

Is this all because it uses the hash symbol? I mean, you could probably call anything a "comment that affects code" if we want to get abstract. Attributes are in a bunch of languages, but they aren't comments. Comparing them to comments just feels like you're ignoring the fact that they are code that affects runtime.

Re: TS to JSDoc Conversion

#129

Post by eyelidlessness »

rcarr wrote: post #54
masklinn wrote: post #36

Earlier quoted context omitted.

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

There’s also a long history of smuggling code into JS comments (JSX pragmas, pure), and seemingly noop directives (“use strict”). They’re all hacky but there’s a very strong resistance in the community to mixing intent with JSDoc (good luck signaling anything to TS or eslint in a JSDoc block!). I think it’s safe to write this possibility off as “probably not inevitable”.

Re: TS to JSDoc Conversion

#130

Post by cxr »

kabes wrote: post #93

I don't care what svelte does, but I've maintained projects with jsdoc types and projects using ts directly and IMO using jsdoc tends to be more of a hassle to maintain, had worse ide guidance and in general felt just more cumbersome. Being able to click through to the implementation in your ide is nice though, but can be solved by the ide.

Synthesizing the JSDoc-formatted type information into a TypeScript-like syntax for those who prefer it can also be solved by the IDE.
Post reply on HN