And yes, threading was a big part of it. See also: https://devblogs.microsoft.com/typescript/typescript-native-...

- LSP monaco - the API in the browser - the CLI in Wasm for platforms we couldn't build

which muddies the water a bit, but I'm sure we can get it working

This wouldn't be a big deal in practice (besides losing the domain). Domain usernames are just the combo of you telling Bluesky "I intend to use this domain name" and then you placing a TXT record on the domain to prove you own it. If you want to change domains (or, are forced to), you just give them the new domain name and you set another TXT record (just like if you had set up a domain name as a username for the first time). The underlying DID is still yours.

> But an explanation is missing! There is no official documentation about how different options interact to say: as I'm walking a file tree as the Typescript compiler, this is how I will interpret a certain file I encounter, what will be outputted, and how that will be interpreted by bundlers and browsers, especially in an ESM world.

Perhaps you missed it, but Andrew (from the TS team) recently finished a massive overhaul of our module docs: https://www.typescriptlang.org/docs/handbook/modules/introdu...

The "theory" page describes TypeScript's perspective on modules. The "reference" page documents things from the "as I'm walking a file tree" perspective (among many other details). The "guides" page also provides recommendations for certain kinds of projects.

Then, a new error about the deprecations of ancient options to be removed in 5.5: https://github.com/microsoft/TypeScript/issues/51909

But I tried my best to make the build have fast paths to minimize the development loop as much as possible.

I didn't consider doing it step by step, no, but I'm not sure how I would really achieve that effectively. The reality is that the bulk of PRs are submitted by the team, and it's straightforward to get everyone to get their code in before this change, pause merges, rebase, and then continue as normal. I'd rather go for the "rip the band-aid off" method.

I have a gameplan to drop this by another 7 MB (by turning our executables into ESM), probably for 5.0 as well if we decide that Node versions older than 12 are worth dropping.

I have tested the merge conflict problem, and thanks to the way the PR is constructed (in steps), git actually does a good job figuring things out.

Potentially, an approach like this might be applicable to other changes; I have a commit in my stack which moves the old build system config to the new build system config's path (even though it's wrong), as git does a much better job understanding where the code is going if you help it.

Thank you for the kind words!

Firstly, the old codebase is TS namespaces, which compile down to IIFEs that push properties onto objects. Each file that declares that namespace is its own IIFE, and so every access to other files incurs the overhead of a property access.

With modules, tooling like esbuild, rollup, can now actually see those dependencies (now they are standard ES module imports) and optimize access to them. In this PR's case, the main boost comes from scope hoisting.

For example, in one file, we may declare the helper `isIdentifier`. In namespaces, we would write `isIdentifier` in another file, but this would at emit time turn into `ts.isIdentifier`, which is slower. Now, we import that helper, and then esbuild (or rollup) can see that exact symbol. All of the helpers get pulled to the top of the output bundle, and calls to those helpers are direct.

That's why modules gives us a boost. There's also more (modules means we can use tooling to tree shake the output, and smaller bundles are faster to load), but the hoisting is the big thing.