Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Speeding up the JavaScript ecosystem – Isolated Declarations

marvinh.dev

Post reply on HN
Print view View original

41–50 of 57 posts

Re: Speeding up the JavaScript ecosystem – Isolated Declarations

#41

Post by rezonant »

stevenpetryk wrote: post #34
rezonant wrote: post #26

Earlier quoted context omitted.

Yes, I recommend shipping TS source alongside compiled JS+d.ts even if you don't support a TS native environment, because you then have the potential of a source mapped debugging experience within that library (though currently doing that is a bit painful in some debuggers).

That can be nice, but do keep in mind that shipping more files leads to a larger tarball downloaded from npm.

Of course. A few more kilobytes is a good tradeoff for debuggability and the ability to read the original code during development. Web apps that get bundled won't include it, ESM web apps won't request them, and if a server side application is sensitive to deployment size, it's trivial to remove source files from all dependencies during build. As an application developer I'd much rather an upstream package provide it and let me strip it out than the opposite.

Re: Speeding up the JavaScript ecosystem – Isolated Declarations

#42

Post by mhagemeister »

_jackwink wrote: post #40

This article is kind of a messy read, isolated declarations feels like it's being used as a mcguffin to advertise the jsr registry. Both may be neat things on their own, but I feel the connection is a bit misleading. Isolated declarations should allow parallelization and faster type checking with tooling that supports it. This shouldn't be changing your build/release process or what you export in your package.json. I…

Author here. Thanks for sharing that feedback. I think I missed the mark by being so used to working with runtimes that natively run TS files, that I forgot that this is not the default for everyone. The article was mostly written from that perspective.

For Node users the isolated declaration feature won't do much other than speed up the creation of the .d.ts files a little. For runtimes that can run TS natively like Deno (disclaimer: I work for Deno) the benefit is much more apparent as you always want the original TS sources, but can generate .d.ts files on the fly for faster type checking.

EDIT: Formatting

Re: Speeding up the JavaScript ecosystem – Isolated Declarations

#43

Post by mhagemeister »

austin-cheney wrote: post #6

whilst reducing the time to create type definition files from minutes, sometimes even hours, down to less than a second. WTF. What kind of project would take long to compile from TS? Windows 11 (if it were TS)? I had a long time personal project that was several megs of code with several hundred types/interfaces. It took 13 seconds to compile. If your application takes hours to compile and is less than a petabyte of…

Author here. That's a good point and maybe a matter of perspective. I've worked on projects where using tsc to generate .d.ts files took close to an hour. Even 13s would be too long in my opinion. It should be instantaneously. I guess it depends on where one's personal tolerance threshold is. I have a bit of a lower one as I easily get distracted and loose flow.

Re: Speeding up the JavaScript ecosystem – Isolated Declarations

#44

Post by rlt »

mmoskal wrote: post #37
rty32 wrote: post #33

...wait. Is the entire article based on the assumption that everyone has Typescript installed in every project? Otherwise, how would publish Typescript files work at all? > We only ever ship build artifacts, the compiled JS and the relevant .d.ts files in a package. Isn't this because anyone, regardless of whether they have use the project in JS or TS, can import the library without caring out how the library code is…

I think most bundlers can handle TS nowadays so you don't actually need tsc.

Technically you still need tsc or an alternative TypeScript compiler like swc, but bundlers sometimes include them in their own dependencies so you don’t have to think about it.

Re: Speeding up the JavaScript ecosystem – Isolated Declarations

#45

Post by mhagemeister »

vinnymac wrote: post #8
austin-cheney wrote: post #6

whilst reducing the time to create type definition files from minutes, sometimes even hours, down to less than a second. WTF. What kind of project would take long to compile from TS? Windows 11 (if it were TS)? I had a long time personal project that was several megs of code with several hundred types/interfaces. It took 13 seconds to compile. If your application takes hours to compile and is less than a petabyte of…

I think they are referring to the manual creation of type definitions. As they mention it in the article.

Author here. Unfortunately, I think worded that a bit confusingly in the article. I'm used to working with runtimes that run TS natively and didn't have to care about .d.ts files myself for a long time. From that perspective creating them by running the tsc compiler feels like a manual step for me.

There are cases where folks write them by hand, but that's not what I had in mind when writing the article. I've rephrased that part a bit to hopefully make it less confusing.

Re: Speeding up the JavaScript ecosystem – Isolated Declarations

#46

Post by mhagemeister »

seniorsassycat wrote: post #20
ericyd wrote: post #11

This doesn't really seem to address my most common packaging pain points in the JS/TS ecosystem (which is the inability to easily use ESM in legacy commonjs applications) but maybe I'm just working in the wrong area? I think the author seriously exaggerates the difficulty of creating type declaration files. It's literally one boolean setting in your tsconfig. I wish they would have given more time to proving the alle…

The article suggests that you ship typescript so the app would compile down to esm or cjs. Node 22 has an experimental flag that supports requiring esm as long as there's no top-level await

Author here. I should've worded that better in the article. The takeaway should not be to publish only TS sources to npm. The whole npm ecosystem is based around the assumption that you ship .js files and doing anything else would break it. I've updated the wording to hopefully make it less confusing.

Re: Speeding up the JavaScript ecosystem – Isolated Declarations

#47

Post by mhagemeister »

matthberg wrote: post #12

The site's down for me, here's an Internet Archive link: https://web.archive.org/web/20240706220437/https://marvinh.d... I've really enjoyed this author's series on optimization techniques explored through non-trivial yet still small case studies, the other articles linked near the top are all worth checking out too!

Oh no, I just woke up and saw this comment. It seems to be up again. Apologies for the inconvenience. Looks like the HN hug of death is real!

Happy to hear that you like the series!

Re: Speeding up the JavaScript ecosystem – Isolated Declarations

#48

Post by mhagemeister »

pzmarzly wrote: post #10

From what I understand, the author is persuading library authors to stop compiling TS->JS, and instead ship your TS files to the users over npm. I like the idea of it, but will it actually work in practice? What if some dependency only compiles with some version of tsc? What if it needs different tsconfig-s?

Author here. I should've worded that better. The recommendation is not to stop compiling TS->JS for npm users. The whole npm ecosystem is built around the assumption that you ship JS and doing anything else would break it.

In Deno (disclaimer: I work for Deno), which supports running TS natively, packaging outside of npm has always worked by shipping the TS files directly. Transpiling them down to JS files is only something you ever had to do when publishing on npm.

So far the problem that a dependency only compiles with a certain version of tsc hasn't popped up since Deno was launched. But that may have been because Deno always ships with latest TS and Deno users don't hesitate to update as we haven't done any breaking changes so far.

Re: Speeding up the JavaScript ecosystem – Isolated Declarations

#49

Post by mhagemeister »

viraptor wrote: post #2

I feel like the point is skipped in the post: if you ship TS sources, it means you need the TS compiler on the installed side, right? And specifically the right TS version for each installed package... which in some cases may mean conflicting requirements? (If you own code is in JS, that is)

Author here. True, I think I should've worded it better. I work for Deno and it being a JS runtime that is able to run TS natively makes this less of an issue. The problem that a dependency needs a specific TS version hasn't come up so far. But that might be because Deno users tend to update to the latest version pretty frequently as we haven't done any breaking changes so far.

Re: Speeding up the JavaScript ecosystem – Isolated Declarations

#50

Post by mhagemeister »

rezonant wrote: post #18

Please do not start publishing raw Typescript into the NPM registry thinking that all the reasons we have not done that in the past do not continue to apply. I shouldn't have to say this, but at least 27 people upvoted this article, so here we are. isolatedDeclarations is most useful for large codebases and other situations where performing a full Typescript compilation is prohibitively expensive. This is not the vas…

Author here. Agree! The whole npm ecosystem is based around npm packages shipping JS files and doing anything else would break it. I've updated the article to hopefully make it less confusing. The takeaway should definitely not to only publish TS files to npm.

I mainly work with Deno which can run TS files natively (disclaimer: I'm employed by them). This changes the parameters a little as all registries for Deno could always ships the TS sources directly. But when publishing to npm you always have to publish the JS sources to work with runtimes like Node that don't support running TS natively.

Post reply on HN