<i>whilst reducing the time to create type definition files from minutes, sometimes even hours, down to less than a second.</i><p>WTF. What kind of project would take long to compile from TS? Windows 11 (if it were TS)?<p>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 source code you have some catastrophic mistakes in your approach.
The blog doesn't explain how to take advantage of isolated modules without using JSR, or how JSR transforms published packages.<p>How would a project configure node and typescript to use a npm module that has exported .ts files?
The site's down for me, here's an Internet Archive link:<p><a href="https://web.archive.org/web/20240706220437/https://marvinh.dev/blog/speeding-up-javascript-ecosystem-part-10/" rel="nofollow">https://web.archive.org/web/20240706220437/https://marvinh.d...</a><p>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!
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.<p>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.<p>If you also happen to use the jsr registry to publish your package, it sounds like you can update your package.json to export TS files and they'll compile/inject the JS into your release artifacts on publish. Not sure if this feature requires isolated declarations though.
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?<p>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.
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?
JavaScript runtimes are full of optimizations that execute conditionally on specific scenarios. If you don't follow the rewarding path of optimization you then go to the deeply unhappy path of deoptimization.<p>It's easy to get started with JavaScript, but to squeeze every bit of performance in JavaScript will quickly get you into a very complex topics that are not documented and change may change from version to version as they are often not "contracts".<p>The only way to learn those obscure topics is by reading the source code for your JavaScript implementation, their bug tracker, etc. This means if you have not been reading C++ or executed a non-JS profiler to make your JS faster then you probably have not gone far enough.<p>There are unexpected things that you would never have suspected if you had not read the implementation.
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?<p>(If you own code is in JS, that is)
I believe the intention behind isolatedModules is to make compilation faster by forcing you to define types that require no inference from other files (thus, being isolated).<p>Not… whatever this is.
<i>Please</i> 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.<p>I shouldn't have to say this, but at least 27 people upvoted this article, so here we are.<p>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.<p>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.<p>EDIT: To be clear, I think it's totally fine to publish your TS source <i>in addition</i> to your JS and d.ts outputs, just don't publish TS only packages, please.
...wait.<p>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?<p>> We only ever ship build artifacts, the compiled JS and the relevant .d.ts files in a package.<p>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 implemented (in JS or TS)? It is not perfect but has worked for almost everyone. How would the author's project layout help people who only ever write code in JavaScript and never installed the Typescript package? Does Typescript have to be a dev dependency of any project that has an upstream package written in Typescript? That seems a bad idea.<p>I write almost all my JavaScript projects with Typescript now (it's a bad sentence but you know what I mean), but I don't think we should ever make the life harder for those who only write in JavaScript.
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).<p>I'll try my best to break it down succinctly:<p>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)<p>2) However, if types were to be fully explicit, then .d.ts generation could be performed without a full type checker (i.e. by a faster compiler via mere syntax transformation)<p>3) The isolatedDeclarations flag causes the TS compiler to trigger errors when any exports would require inference in order to generate .d.ts<p>4) Thus, the isolatedDeclarations flag can be used to guarantee compatibility with faster, simpler .d.ts generation using syntax-based transformation<p>5) A consequence of simpler .d.ts generation is that it can be trivially done in parallel, which can be helpful for large monorepos