[HN Gopher] TS to JSDoc Conversion
___________________________________________________________________
TS to JSDoc Conversion
Author : ajhenrydev
Score : 176 points
Date : 2023-05-10 18:20 UTC (4 hours ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| ilrwbwrkhv wrote:
| yes this is much better. to be able to reach the actual source
| code which makes a function run is something we have all lost
| with so many layers in the middle.
| zoogeny wrote:
| A decent expanded explanation of why in this YouTube video:
| https://www.youtube.com/watch?v=MJHO6FSioPI&ab_channel=Svelt...
| rich_harris wrote:
| 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.
|
| Firstly: we are not abandoning type safety or anything daft like
| that -- we're just moving type declarations from .ts files to .js
| files with JSDoc annotations. As a user of Svelte, this won't
| affect your ability to use TypeScript with Svelte at all --
| functions exported from Svelte will still have all the same
| benefits of TypeScript that you're used to (typechecking,
| intellisense, inline documentation etc). Our commitment to
| TypeScript is stronger than ever (for an example of this, see
| https://svelte.dev/blog/zero-config-type-safety).
|
| I _would_ say that this will result in no changes that are
| observable to users of the framework, but that's not quite true
| -- it will result in smaller packages (no need to ship giant
| sourcemaps etc), and you'll be able to e.g. debug the framework
| by cmd-clicking on functions you import from `svelte` and its
| subpackages (instead of taking you to an unhelpful type
| declaration, it will take you to the actual source, which you'll
| be able to edit right inside `node_modules` to see changes
| happen). I expect this to lower the bar to contributing to the
| framework quite substantially, since you'll no longer need to a)
| figure out how to link the repo, b) run our build process in
| watch mode, and c) understand the mapping between source and dist
| code in order to see changes.
|
| So this will ultimately benefit our users and contributors. But
| it will also benefit _us_, since we're often testing changes to
| the source code against sandbox projects, and this workflow is
| drastically nicer than dealing with build steps. We also
| eliminate an entire class of annoying papercuts that will be
| familiar to anyone who has worked with the uneven landscape of
| TypeScript tooling. The downside is that writing types in JSDoc
| isn't quite as nice as writing in TypeScript. It's a relatively
| small price to pay (though opinions on this do differ among the
| team - this is a regular source of lively debate).
|
| We're doing this for practical reasons, not ideological ones --
| we've been building SvelteKit (as opposed to Svelte) this way for
| a long time and it's been miraculous for productivity.
| benmccann wrote:
| I was skeptical at first when we made the change in SvelteKit.
| However, SvelteKit has a large integration test suite and being
| able to change the code and rerun the tests against the real
| final version of the code without waiting for any build step to
| complete has been a big improvement to productivity and I'm now
| a big fan of having made the change there. The tradeoff may be
| a bit different in Svelte core where we have more unit tests
| and fewer integration tests, so we're still investigating and
| considering the change, but we do have experience with both
| approaches and at the end of the day great software can be
| built using either approach.
| javajosh wrote:
| Great move, Rich! It's quite enjoyable working without
| sourcemaps.
|
| I'll add that IntelliJ+Copilot makes writing solid JSDoc very
| fast and easy.
| PaulMest wrote:
| 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.
| bottlepalm wrote:
| 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.
| preommr wrote:
| > 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 out there. Sourcemap file size is a
| non-issue, they're not gigabytes, and editors like vscode now
| support going to the source definition for projects that
| support it. To completely switch over to js and then set types
| that way seems regressive. Just so that people can modify the
| source code directly a little bit easier? There are all kinds
| of tools ranging from ts-node-dev that make watching typescript
| files easy, with options to skip type checking for better
| speed. Honestly seems kind of backwards.
| _gruntled wrote:
| > 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 completely switch over to js and then set types that way
| seems regressive.
|
| "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.
| deprecative wrote:
| > "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.
| _gruntled wrote:
| 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.
| capableweb wrote:
| > tbh, this seems pretty far out there. Sourcemap file size
| is a non-issue, they're not gigabytes
|
| Sure, by themselves, but replicate that across everyone
| repeatedly downloading the library in various build
| processess, in various projects and with different versions.
|
| Sure, by itself a sourcemap might not add up to much. But
| then there is various projects with different versions, who
| download the library repeatedly in different build steps.
| Then it starts to add up both in bandwidth, and in storage
| taken.
|
| Luckily, there are still package and library maintainers who
| care about making things less, instead of more, both in
| architectures and size.
|
| > Just so that people can modify the source code directly a
| little bit easier?
|
| This is a real thing that is useful to think about, how to
| make your software easier to change in the future, while just
| solving the current concern without over-engineering the
| solution.
| gred wrote:
| 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.
| inglor wrote:
| 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 for free refer to each other internally.
| cjohnson318 wrote:
| > 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.)
| EGreg wrote:
| We also demand that they stop working on any web3 integrations
| because it's useless and we dont like it
| rcme wrote:
| I think the reason is that the change just sounds so insane at
| face value that many can't help but comment on it.
| lucasyvas wrote:
| 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.
| mirekrusin wrote:
| Type imports are the worst.
| dTP90pN wrote:
| 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?
| joduplessis wrote:
| I love pure JS over TS any day, but isn't this using JSDoc in a
| way it's not meant to be used? Why would you use JSDoc as a JS
| type framework? Or is the post title a bit misleading...?
| gizmo wrote:
| Because this way you get amazing IDE support with code
| navigation, refactoring, and (with strict mode) warnings about
| likely bugs and missing null checks.
| phpnode wrote:
| this is exactly what JSDoc is for, it's had these capabilities
| from the start.
| brundolf wrote:
| *Svelte compiler. Users of Svelte are unaffected
|
| I don't know the details of their situation, but I definitely can
| relate to the build step being a huge pain in the butt for Node
| projects. It's why I've stopped using Node whenever I can afford
| to, in favor of Deno (or maybe one day Bun). I used Deno to build
| a compiler for a personal language project recently, and it was
| an absolute delight not having to deal with any of Node's BS.
| Assuming they can't afford to migrate runtimes at this stage, I
| definitely get why they'd explore other options
| bottlepalm wrote:
| Wow so much overhead, but I can see why if the problem is trying
| to step into some npm package code - landing on a type definition
| file is not helpful
|
| It makes you think why can't the TS compiler produce JS code with
| JSDoc annotations instead of source maps. Ship the node packages
| with that so that debugging into the framework is seamless and
| easy to edit.
| givemeethekeys wrote:
| A bit off-topic (sorry):
|
| Is anyone using Svelte in production without SvelteKit?
|
| Hows Svelte documentation as of late?
| TehShrike wrote:
| I've been using Svelte in production without SvelteKit for
| around 5 years now. The docs have always been pretty great in
| my opinion
| arzke wrote:
| Is there any reason you wouldn't want to use SvelteKit now
| that is has reached version 1.0?
| TehShrike wrote:
| 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.
| sanitycheck wrote:
| 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).
| wirahx wrote:
| 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.
| endisneigh wrote:
| [flagged]
| rich_harris wrote:
| appreciate the insightful comment
| POiNTx wrote:
| Little side note, I'm always in awe of the amount of crap open
| source developers have to take from the community vs the crazy
| amount of value they offer. There's a lot of backlash on
| something 99% of commenters will never have to interact with. A
| lot of knee jerk reactions without trying to understand what's
| going on. And in return projects like Svelte offer an insane
| amount of value for people and businesses. Thankless work.
|
| Nowadays it's expected that you get software for free, and if you
| don't like it you have the moral right to complain at insane
| lengths at the maintainers of this software. Even if you don't
| agree with certain decisions (which in this case shouldn't even
| be the case), there's a way of going about things, you're dealing
| with people, not faceless corporations.
| nepeckman wrote:
| 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]
| rcarr wrote:
| 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
| recommended way of doing things. Absolute madness.
|
| https://symfony.com/doc/current/routing.html
| leoedin wrote:
| Are they not using attributes, which start with a #? I thought
| PHP had C style // comments.
| jjice wrote:
| 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.
| rcarr wrote:
| 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.
| supriyo-biswas wrote:
| That's a PHP attribute:
|
| https://php.watch/articles/php-attributes
| jjice wrote:
| I don't see any comments there, I see attributes though [1]. Is
| that what you meant?
|
| From the page you linked:
|
| > Routes can be configured in YAML, XML, PHP or using
| attributes. All formats provide the same features and
| performance, so choose your favorite. Symfony recommends
| attributes because it's convenient to put the route and
| controller in the same place.
|
| Attributes are not comments, they are an official structured
| way of handling metadata.
|
| [1]
| https://www.php.net/manual/en/language.attributes.overview.p...
| rcarr wrote:
| I'm sorry, but if it's using the same starting symbol as a
| comment, and it's greyed out in the text editor like a
| comment, then you can call it whatever you want, but it is a
| fucking comment. There are a bunch of unused symbol
| combinations on the keyboard that could have been used, there
| is absolutely no excuse for it.
| alpaca128 wrote:
| > it's using the same starting symbol as a comment
|
| In Java the keywords "public" and "private" use the same
| starting symbol too, what's your point? Attributes start
| with "#[", comments with "//" or "#". That's clear enough.
|
| > it's greyed out in the text editor like a comment
|
| A language isn't responsible for a specific text editor's
| syntax highlighting.
| rcarr wrote:
| > A language isn't responsible for a specific text
| editor's syntax highlighting.
|
| It's even greyed out like a comment in the official
| symfony documentation.
| masklinn wrote:
| > 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 how that code interacts with
| other systems.
| rcarr wrote:
| > 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.
| apocalyptic0n3 wrote:
| 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.
| kamikaz1k wrote:
| where does it say that JSDoc has runtime implications?
| rcarr wrote:
| It doesn't and I say in my comment that it is not the same
| thing. Nevertheless it gives me the same uneasy feeling
| because you don't know what features are going to creep into
| the language further down the road.
| madeofpalk wrote:
| It seems extremley unlikely that Javascript would ever make
| comments affect the runtime of the language. I'm not sure
| why there's a fear here why browser vendors/es standards
| comittees would opt to go down this road?
| masklinn wrote:
| You're literally not making any sense.
|
| JSDoc is like 20 years old and not part of the javascript
| langage, it's just a way of formatting _some_ comments such
| that they're programmatically process able.
| brundolf wrote:
| > has comments that affect how the code runs
|
| > Reading about JSDoc gives me the same uneasy feeling, even if
| it's not quite the same thing
|
| The key difference with TypeScript is that even "real"
| TypeScript types never ever affect runtime behavior, they are
| purely descriptive. This is an explicit goal of the project
| (and they've had to make some compromises in other areas to
| uphold it), so I don't see it ever changing
| philo23 wrote:
| 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...
| rcarr wrote:
| > might look like a comment, but they are actually just valid
| bits of code
|
| So comments that are code then.
|
| Everyone can sit around going "This is not a pipe it's a
| photo of a pipe or my perception of a photo of a pipe". But
| if you did not have a sentence above your photo saying "This
| is not a pipe" or an arts teacher to tell you "this is not a
| pipe" and there was just a picture of a pipe on the page and
| someone pointed at it and said "can you tell me what that
| is?" You would say "why of course, it's a pipe". And then all
| of a sudden it started spouting water out of the end (let's
| assume it was a GIF) then you can say "oh it looks like a
| pipe but it's actually a water pistol masquerading as a
| pipe". The fact that as a dev you have to constantly be on
| the look out for water pistols masquerading as pipes rather
| than having a clear distinction between pipes and water
| pistols is just a piss poor and easily avoidable design
| decision.
|
| https://en.m.wikipedia.org/wiki/The_Treachery_of_Images
| sdwvit wrote:
| JSDoc and Typescript don't have feature parity: OOP that works
| across files, generics, inline types, etc.
| rich_harris wrote:
| 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.
| zdragnar wrote:
| 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.
| rich_harris wrote:
| If those libraries were set up correctly, this would cause
| typechecking to fail.
| protonimitate wrote:
| For those that didn't read the thread - this is for the Svelte
| compiler, not the Svelte library. Users of Svelte will be
| unaffected and typedefs will still be available.
| antoineMoPa wrote:
| Why would anyone do this?
| mxkyb wrote:
| In general, your code is still valid JavaScript and can run in
| any browser or node environment. Typescript probably is not
| going to disappear, but if it would, your code wouldn't have to
| change. And you don't loose your types, because the typescript
| compiler can interpret jsdoc as if you were using typescript
| directly.
| rcme wrote:
| > 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 now, so there will
| be no change for Svelte developers in terms of typing.
|
| Someone who maintains the JS debugger for VS Code added this
| (in response to a Svelte developers saying they couldn't use a
| faster compiler due to debugging difficulty):
|
| > It's an aside from the main PR, but I'm not entirely sure
| what you mean here. This should not exclude the ability to use
| alternative TS compilers--in fact, the js debugger itself is
| built with esbuild. The debugger should also handle runtime
| transpilers (like tsx) just fine.
| maxloh wrote:
| Why don't them just use `tsc --watch`?
| yid wrote:
| ts-node [1]: am i a joke to you?
|
| [1] https://www.npmjs.com/package/ts-node
| nailer wrote:
| ts-node is responsible for my favourite error message in
| all of computing.
|
| Yes better than: 'Error: success' or 'keyboard not found:
| press F1 to continue'
|
| > ts-node: Unknown file extension: ts.
|
| Someone will reply for a technical reason about this
| (mentioning .mts or package.json settings or whatever) but
| that doesn't change the fact that a program whose only job
| is to run ts files should know what a ts file is. GitHub
| issue: https://github.com/TypeStrong/ts-node/issues/1967
|
| tsx or @digitak/esrun both work out of the box.
| johnfn wrote:
| I'm glad you mentioned this - I had the exact same issue
| when using ts-node and it really blew my mind.
| mattwad wrote:
| ts-node does not play well with ESM modules out of the box.
| I've started experimenting with tsx but it still has some
| edge cases of its own. Honestly, ESM has been the bane of
| my existence this year as packages are slowly starting to
| migrate, and fixing issues lays on the developer, not any
| one framework.
| Tade0 wrote:
| Overall the shift to ESM has been one hell of a dumpster
| fire.
|
| And introducing new extensions like _.mjs or_.cjs is the
| smoldering dead raccoon responsible for half of the
| smell.
| rcarr wrote:
| I've generally found tsx to be better/less hassle than ts-
| node
|
| https://github.com/esbuild-kit/tsx
| jjice wrote:
| Oh very cool, I'll have to look into this because ts-node
| can be a pain sometimes. Unfortunate name collision with
| the TS equivalent of JSX though.
| paiari wrote:
| 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 <file>.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
| fpoling wrote:
| 10 years ago I have used Closure compiler from Google,
| https://github.com/google/closure-compiler/wiki/Annotating-T...
| , as a type checker. We had to use for production a different
| minimizer, not the closure compiler, but it was extremely
| useful to check for types and JSDoc-style annotations were very
| readable with minimal distraction.
|
| Flow for JS from Facebook also supports types-as-comments,
| https://flow.org/en/docs/types/comments/ , but those are rather
| ugly as one has to intermix them with JS rather than using
| separated comment block on top.
| djbusby wrote:
| To keep the benefits of Types w/o the burden of TS.
| merb wrote:
| with the difference that typescript generates the types
| automatically or at least tries to and in JSDoc the user
| needs to write the JSDoc.
|
| Edit, btw: Most complex types in the MR are now completly
| broken. It's crazy that there is a serious project out there
| who tries to mix jsdoc and typescript interfaces in the same
| project. it's like getting bad things from two worlds.
| mxkyb wrote:
| Just add some interfaces.d.ts and import those types into
| jsdoc and you still have all your complexity
| fpoling wrote:
| With modern IDE writing JSDoc comments is a fast process
| [deleted]
| kabes wrote:
| 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.
| ajhenrydev wrote:
| Twitter thread about it
| https://twitter.com/puruvjdev/status/1655813548495486977
| tbjgolden wrote:
| 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 files can be awkward, and cross importing is awkward. fwiw
| created my own tool for this (https://github.com/tbjgolden/xnr)
| hn_throwaway_99 wrote:
| > but they are just writing the files in JS with JSDoc type
| annotations
|
| I think this is the critical piece not everyone understands.
| Under the covers, it's basically still Typescript (see
| https://www.typescriptlang.org/docs/handbook/intro-to-js-
| ts....). The major difference is that type information is
| specified in comments so that the source file is still valid JS
| and thus doesn't need a separate compilation step. There is not
| an exact parity between type info that can be specified with
| JSDoc and Typescript, but my understanding is that it's pretty
| close.
|
| Any folks familiar with Flow (before Typescript essentially won
| out), Flow had something similar that was very nice, IMO better
| because it was the same Flow syntax, just wrapped in comments:
| https://flow.org/en/docs/types/comments/
| skrebbel wrote:
| XNR looks nice! I'm impressed that it can be faster than
| esbuild-runner, is there a downside?
| tbjgolden wrote:
| I know why it's fast (it doesn't do anything it doesn't need
| to), but not _exactly_ sure why it 's faster than esbuild-
| runner; presumably it had a higher latency when tested.
|
| (and downsides not really, beyond it's pretty fresh so bug
| reports welcome)
| maxloh wrote:
| What is the reason behind choosing sucrase over swc?
|
| FYI, you committed the wrong license file. The license file
| contains license text of a standard MIT License, but your
| project is licensed under Apache...
| echeese wrote:
| TS can generate d.ts files from JS files that use JSDoc
| tbjgolden wrote:
| ty, updated
| rkeene2 wrote:
| 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
| dobladov wrote:
| 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 pure JS.
| makapuf wrote:
| This is great but -if I dare - wouldn't it be time to allow js
| to have type annotations [1] ? As in python, treat it as
| comments for now but with real syntax and let interesting
| dialects emerge from the consensus ? I like jsdoc but the
| syntax is urgh.
|
| [1] https://github.com/tc39/proposal-type-annotations
| herpdyderp wrote:
| It will be impossibly exciting if that proposal happens. I
| hate build steps, one of the reasons I latched onto JS for my
| career, but TS is just so good that I had to go full blast
| with it after using it for the first time.
| paulddraper wrote:
| TS compiler should have an CLI option to compile without type
| checks.
|
| TS features don't need types to produce output[1] and this is
| supported by the compiler; it just doesn't have a CLI option.
|
| Compiling without types is supported the compiler itself (this
| is what Babel does).
|
| [1] Except const enum and export *
| Rapzid wrote:
| It's really VERY easy to use something like esbuild or SWC
| though and just use TS for doing checks on the side. SWC
| would have ripped the TS annotations out of the top 100 TS
| projects on GitHub before I even finished typing this
| sentence.
| alerighi wrote:
| > 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.
| mxkyb wrote:
| and you can always define more complex types in interfaces
| and import into jsdoc.
| mjjp wrote:
| Yes you can with @typedef and @template
| mdaniel wrote:
| 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)_
| Tade0 wrote:
| > 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
| MrJohz wrote:
| What your build/deployment steps without the Typescript syntax?
| Do you bundle or minify at all, or do you release your source
| files directly? Or is this mostly for NodeJS/server side stuff?
|
| I ask because for most of my projects there's at least some
| bundling going on, and in that case the added complexity of
| Typescript compilation is pretty minimal - with tools like Vite
| there is no added complexity, because JS and TS files are going
| down exactly the same pipeline, parsed by the same parser, etc.
| And I could get rid of the bundler, which would make some
| things simpler, but makes imports and deployment more
| complicated. For the scale of projects that I'm working on,
| bundling feels like necessary complexity.
|
| I guess I'm trying to figure out if this is a useful form of
| minimalism for the sorts of projects I work on, or if this is
| the sort of thing that works for some projects but not others.
| Zamicol wrote:
| 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.
| rcme wrote:
| What kind of pitfalls are you talking about?
| Zamicol wrote:
| _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.
| hn_throwaway_99 wrote:
| 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
| you are saying is that there is no native `sizeof` operator
| for Objects, but this doesn't seem like some crazy
| decision.
| rpearl wrote:
| If you've got enough keys that it matters you probably want
| to use a `Map` instead of an object? Maps are faster to
| write and read is approximately the same.
| quest88 wrote:
| Of course it does. You're calling a static function that
| procudes an array. You want to use a Map and use its size
| property.
| jiripospisil wrote:
| 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.
| jgalentine007 wrote:
| As someone who has had a large project go from TypeScript ->
| TS/JsDoc -> back to TypeScript... I was NOT a fan of trying to
| use JsDoc for types.
| riogordo2go wrote:
| I remember not using/trying Svelte because there was no TS
| support and it took quite some time before TS support emerged.
| With that in mind it doesn't surprise me they are not doubling
| down on TypeScript.
| npretto wrote:
| this has nothing to do with "TS support" at all.
| porsager wrote:
| 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.
| nickreese wrote:
| Used to be really active in the svelte community and developed my
| own framework that got broad use. Getting Svelte and TS working
| together was a constant battle. This is a good decision.
| benmccann wrote:
| Svelte will still provide type definitions. We're working on
| Svelte 4 currently and are taking the opportunity to make a few
| small breaking changes to the type definitions for improved
| TypeScript support:
| https://github.com/sveltejs/svelte/blob/version-4/CHANGELOG....
|
| We'll cut a preview release soon and would love help testing
| and feedback from folks that have given it a try.
| progx wrote:
| 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.
| bilalq wrote:
| 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.
| rich_harris wrote:
| You are making judgements based on a draft PR. There is a ton
| of work still to do.
| bilalq wrote:
| 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.
| Rapzid wrote:
| > There is a ton of work still to do.
|
| What's the estimated ROI?
| postalrat wrote:
| That depends on how much you value getting a bunch of
| developers to think about svelte, jsdoc, and typescript.
| myvoiceismypass wrote:
| Maybe I am unfamiliar with jsdoc, or what the shape of Node
| from acorn is, but yeah if every function is returning any,
| that seems like a big downgrade and sacrifice.
| _gruntled wrote:
| 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.
| bilalq wrote:
| Fair enough. Minor nit, the PR is not actually marked as a
| draft.
___________________________________________________________________
(page generated 2023-05-10 23:01 UTC)