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

11–20 of 57 posts

Re: Speeding up the JavaScript ecosystem – Isolated Declarations

#11

Post by ericyd »

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 alleged pain points with some examples rather than just telling us how great this new feature is. I personally don't see how this changes my life at all, and I'm a full time JS/TS dev.

Re: Speeding up the JavaScript ecosystem – Isolated Declarations

#12

Post by matthberg »

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!

Re: Speeding up the JavaScript ecosystem – Isolated Declarations

#13

Post by rezonant »

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.

But then they assume the code is authored in Typescript... Who is authoring in Typescript and then simultaneously writing their d.ts manually?? It makes no sense.

Re: Speeding up the JavaScript ecosystem – Isolated Declarations

#14

Post by rezonant »

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?

> but will it actually work in practice?

No. It seems like they are assuming the user is using JSR, which handles generation of JS and d.ts for you. But then none of this would even be a problem.

The NPM registry doesn't do any of that. You could absolutely publish only .ts files to NPM and then use a post install script to generate JS and d.ts files, but that is a pretty terrible idea. Even if the process is super fast, it's still an operation done potentially millions of times, versus an operation which can happen once at publish time. You could also assume the user will have their own mechanism for compiling TS or consuming TS directly, but this is even worse.

Re: Speeding up the JavaScript ecosystem – Isolated Declarations

#15

Post by austin-cheney »

rezonant wrote: post #13
vinnymac wrote: post #8

Earlier quoted context omitted.

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

But then they assume the code is authored in Typescript... Who is authoring in Typescript and then simultaneously writing their d.ts manually?? It makes no sense.

I write all my d.ts files manually. Maybe that’s the problem: people don’t know how to write TS, expect some software to do it for them, and then end up waiting hours on a build that should take 10 seconds.

Re: Speeding up the JavaScript ecosystem – Isolated Declarations

#16

Post by rezonant »

rtsao wrote: post #3

I've heard of `isolatedDeclarations` in TS 5.5, but this post left me with more questions than answers because it conflates so many distinct things (TS 5.5, Deno, JSR). I'll try my best to break it down succinctly: 1) Historically, .d.ts generation is slow because it requires the full TypeScript type checker in order to correctly handle all cases (e.g. exported functions with inferred return types) 2) However, if typ…

This is all fully correct, which is why isolatedDeclarations is a nice feature... for authors of large Typescript projects. The tradeoff is to be more explicit on your public API surface so that you can reduce build times. That's great.

It really doesn't do the things the author thinks it does.

Re: Speeding up the JavaScript ecosystem – Isolated Declarations

#17

Post by rezonant »

austin-cheney wrote: post #15
rezonant wrote: post #13

Earlier quoted context omitted.

But then they assume the code is authored in Typescript... Who is authoring in Typescript and then simultaneously writing their d.ts manually?? It makes no sense.

I write all my d.ts files manually. Maybe that’s the problem: people don’t know how to write TS, expect some software to do it for them, and then end up waiting hours on a build that should take 10 seconds.

This confuses me. You either write the d.ts manually before build, which only makes sense if you wrote the original code in JavaScript (not Typescript) or you write the source in Typescript and enable the declaration option in your tsconfig and the d.ts pops out in seconds along with your final JS output.

Unless you are using transpileOnly, generating declarations will not make a few second build become a few hours-- Typescript is already type checking your code.

Re: Speeding up the JavaScript ecosystem – Isolated Declarations

#18

Post by rezonant »

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 vast majority of cases. It is the declarations analog of transpileOnly, which skips all type checks and simply strips Typescript's special syntax.

The author seems to assume use of JSR, which is an alternative to the NPM registry which automatically compiles Typescript. Not being terribly familiar with it, it's possible this is more relevant to users of that registry, but it's not clear why this is an issue when the registry itself is handling transpiling and declaration generation.

EDIT: To be clear, I think it's totally fine to publish your TS source in addition to your JS and d.ts outputs, just don't publish TS only packages, please.

Re: Speeding up the JavaScript ecosystem – Isolated Declarations

#19

Post by crooked-v »

streptomycin wrote: post #9
seniorsassycat wrote: post #7

The blog doesn't explain how to take advantage of isolated modules without using JSR, or how JSR transforms published packages. How would a project configure node and typescript to use a npm module that has exported .ts files?

You wouldn't, you would use JSR.

I despise this recurring trend in the JS-adjacent world of "cutting edge" people making their published packages intentionally incompatible with what everyone else is doing.

Re: Speeding up the JavaScript ecosystem – Isolated Declarations

#20

Post by seniorsassycat »

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

Post reply on HN