PR that converts the TypeScript repo from namespaces to modules

Alingment is leading whitespace that is expected to match the width of some non-whitespace text above, indentation is leading whitespace that is just expected to match all other indentations (* level). When indentation is scaled through editor reconfiguration, alignment should stay the same.

What I think gp is underestimating is just how much alignment there was in the old days, and how little (compared to now) indentation. From today's perspective, indentation is the norm and alignment is the rare exception. Your question is a good illustration: sounds like you never met alignment, or at least never noticed it. But back then, alignment was a very regular occurrence and the extra diligence required for getting all the tabs and blanks right to look nice on different tab widths, or the ugliness from failing to get the mix right would have been a considerable cost. Avoiding unpredictably wide tabs was a reasonable call.

Hmm, what is it that Node is doing that’s so bad? I don’t understand why that issue is a big problem.

This explanation in the comments makes sense to me:

Transpilers can add the ability to add extensions at compile time, so a specifier like './file' can be rewritten to './file.js' during compilation along with whatever else is getting converted by the transpiler.

It seems sensible for Node to expect fully-qualified imports, just like a browser would. And (to me) it seems sensible that in a language like TypeScript you should be able to import “foo.ts” and it have it transpiled to the correct filename.

Now, that does not work in TS because they adamantly refuse to modify any of the emitted JavaScript code at all, with no clear explanation except that it’s long-standing policy. Instead they expect you to import “foo.js” in TypeScript, even though that file doesn’t exist until after compilation. That’s a problem, and it seems like it’s caused by the TS team, not Node.

As someone that contributed to swc-cli, surcease benchmarks are pretty bad. SWC run in sync mode, blocking main thread, in addition they are not using benchmark.js or isolated tests.

See in my fork, swc is winning :P https://github.com/chyzwar/sucrase

Once swc-cli is re-written in rust with better IO results could be even more impressive.

Hi, Sucrase author here.

To be clear, the benchmark in the README does not allow JIT warm-up. The Sucrase numbers would be better if it did. From testing just now (add `warmUp: true` to `benchmarkJest`), Sucrase is a little over 3x faster than swc if you allow warm-up, but it seemed unfair to disregard warm-up for the comparison in the README.

It's certainly fair to debate whether 360k lines of code is a realistic codebase size for the benchmark; the higher-scale the test case, the better Sucrase looks.

> worse it disables esbuild and swc's multi-threading

At some point I'm hoping to update the README benchmark to run all tools in parallel, which should be more convincing despite the added variability: https://github.com/alangpierce/sucrase/issues/730 . In an ideal environment, the results are pretty much the same as a per-core benchmark, but I do expect that Node's parallelism overhead and the JIT warm-up cost across many cores would make Sucrase less competitive than the current numbers.

Browsers never required extensions, see https://unpkg.com/ You can load scripts in browser just fine without extension.

> Now, that does not work in TS because they adamantly refuse to modify any of the emitted JavaScript code at all, with no clear explanation except that it’s long-standing policy. Instead they expect you to import “foo.js” in TypeScript, even though that file doesn’t exist until after compilation. That’s a problem, and it seems like it’s caused by the TS team, not Node.

I think they should provide a better explainer. But node.js resolution algorithms is already incredibly complicated, and adding path rewriting to typescript is not going to make it better. There are things like dynamic import and third part libraries. Typescript would need to either analyze whole of project node_modules or bundle custom runtime resolver like webpack breaking compact with deno and friends.

Imagine situation:

  import lib from 'somelib/subpath'

How TS would know that some lib have extension in subpath and it need to add/remove js ext? https://nodejs.org/api/packages.html#extensions-in-subpaths What if typescript is running in deno/bum or wasm?

> Hmm, what is it that Node is doing that’s so bad? I don’t understand why that issue is a big problem.

My conclusion is that successful projects without BDFL are prone to corporate takeovers. You have people that working in corporations without writing code and want to make political career as "core" team member of project.