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).
Not… whatever this is.
Speeding up the JavaScript ecosystem – Isolated Declarations
31–40 of 57 posts
Re: Speeding up the JavaScript ecosystem – Isolated Declarations
#32Earlier quoted context omitted.
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--…
I write TypeScript projects in TypeScript from the start. If I have an existing JS project that needs to port to TypeScript then I will rewrite it entirely in TypeScript. Yes, that takes some small amount of time, but it’s never a complete rewrite. It’s mostly just minor syntax updates as the actual runtime should remain the same as validated by test automation. I type everything I declare whether a primitive or not.…
But why would any of that need to be done manually in a .d.ts file? You can just write your type definitions in ts files
Re: Speeding up the JavaScript ecosystem – Isolated Declarations
#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 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.
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.
Re: Speeding up the JavaScript ecosystem – Isolated Declarations
#34Earlier quoted context omitted.
You can specify different exports based on environment in the package.json so you could ship TS files… alongside JS files, so it feels a little redundant.
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.
Re: Speeding up the JavaScript ecosystem – Isolated Declarations
#35whilst 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…
You seem confused about what .d.ts files are. They are type definitions to make using JavaScript code in typescript nicer. They're not regular typescript code.
Just think if you had to take a big JavaScript library, say the size and level of dynamism of jQuery, and manually write annotations for it yourself.
It would indeed take you hours to cover everything.
Re: Speeding up the JavaScript ecosystem – Isolated Declarations
#36JavaScript 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.
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".
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.
There are unexpected things that you would never have suspected if you had not read the implementation.
Re: Speeding up the JavaScript ecosystem – Isolated Declarations
#37...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.
Re: Speeding up the JavaScript ecosystem – Isolated Declarations
#38I 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)
You would be probably better off just running esbuild or similar - it will happily strip types from any version of TS.
Re: Speeding up the JavaScript ecosystem – Isolated Declarations
#39Earlier 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.
Maybe if writing .d.ts-es by hand was a proper way to write TS, people would know about that from the docs. Don’t sell your fetishes as some sort of a common knowledge please, it doesn’t help anyone.
Re: Speeding up the JavaScript ecosystem – Isolated Declarations
#40This 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.
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.