Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

PR that converts the TypeScript repo from namespaces to modules

github.com

Post reply on HN
Print view View original

81–90 of 204 posts

Re: PR that converts the TypeScript repo from namespaces to modules

#81

Post by Chyzwar »

bigyikes wrote: post #39
redox99 wrote: post #33

I absolutely hate how with Typescript and ES Modules, if you have a file utils/foo.ts you have to import it as import Foo from "utils/foo.js" Even though there is no .js file on disk, and you might be running ts-node or whatever that doesn't build a .js file. Importing a file that "doesn't exist" is so counterintuitive. In addition all code breaks because you have to change all your imports, and /index.ts or /index.j…

Every TypeScript project I have worked on either: 1) enforces no extension, e.g. “utils/foo”, or 2) allows TS extensions, e.g. “utils/foo.ts” I have never imported a TS file using a JS extension. Maybe your woes could be fixed with a configuration change?

No, you were using non-standard ESM modules (compiled to CommonJS defined by babel) Typescript recently added support for ESM compatible with node.js see "module": "node16"[1][2]

The Whole ESM saga is clusterfuck, not much better than python 2 -> 3 migration. Large node.js codebases have no viable path to migrate, and most tools still cannot support ESM properly[3]. Stuff is already breaking because prolific library authors are switching to ESM.

As someone that maintain large part of TS/JS tooling in my day job, I absolutely despise decisions made by node.js module team. My side projects are now in Elixir and zig because these communities care about DX.

  [1] https://nodejs.org/api/esm.html#differences-between-es-modules-and-commonjs
  [2] https://www.typescriptlang.org/docs/handbook/release-notes/typescript-4-7.html
  [3] https://github.com/facebook/jest/issues/9430

Re: PR that converts the TypeScript repo from namespaces to modules

#82

Post by cxr »

merb wrote: post #38
RyanCavanaugh wrote: post #32

Earlier quoted context omitted.

I don't see how this is a rebuttal to the claim. 636,975 is more than 2x 304,526, so assuming the quoted paragraph is correct, sucrase is still the highest-throughput transpiler even during its warm-up phase. Probably this isn't true for the first 100 milliseconds of execution during the very first warm-up stages, but if the transpile phase is that short, it's basically irrelevant anyway.

the warm-up phase is the whole reason why esbuild and swc exists btw. and also the sample is basically a small hello world. any real project would do a little more and the jit would not optimize as much. also 2x 300k is not really the way how multi-threading/concurrency/parallelism works... especially not golang, which should not be run with GOMAXPROCS=1....

As far as I can follow your argument, it seems to be that the native tools perform better on the small inputs (that only ever take a second or three to complete), and that the creators ("maintainers"?) of Sucrase have their thumb on the scale or something, since they emphasize in their results the very large inputs that will involve longer running jobs where their tool has had a chance to warm up. In other words, the tools you're defending only do better when it doesn't really matter, and the tool you're downplaying outperforms the competition on the jobs where it actually does matter. If anything is backwards (or "stupid", as you put it) then that seems to be it.

Maybe I'm misunderstanding. In that case, please provide a better benchmark.

Re: PR that converts the TypeScript repo from namespaces to modules

#83

Post by throwup »

CodeWriter23 wrote: post #52
zebracanevra wrote: post #29

After this change, the TypeScript compiler will now be compiled with esbuild. I feel like thats probably the best endorsement esbuild could get, hah. Surprising they call out the 2 space indent level that esbuild is hardcoded[1] to use as a benefit. Why not save even more bytes and re-format the output to single tab indentation? I wrote a simple script to replace the indentation with tabs. 2 indent size: 29.2MB, tabb…

> Why not save even more bytes and re-format the output to single tab indentation? For your answer search "programmers who use spaces make more money"

I wish they had broken down that survey question further to find out _how many_ spaces the highest paid developers use. Then I could finally have a data-driven answer to put in my prettier config!

Re: PR that converts the TypeScript repo from namespaces to modules

#84

Post by throwup »

Does anyone have any insight about how to coordinate this kind of change to a large project? This kind of change touches literally every file, so every branch will have merge conflicts. The best idea I can think of is to announce the date ahead of time and make every contributor rebase their branches on the day of the merge. But there has to be a better way.

> | edit [–] | on: PR that converts the TypeScript repo from namespac...

Re: PR that converts the TypeScript repo from namespaces to modules

#85

Post by Chyzwar »

longrod wrote: post #8

Sucrase is proof that JS is not the problem when it comes to slow performance. JS is not slow. NodeJS is not slow. It's the code that is slow. All these people wanting to write it in Rust or Go or XYZ programming language need to acknowledge this. Yes, multithreading is awesome and really helpful but it's the cherry on top, not the whole thing. If the same amount of effort was put into optimizing the TSC codebase as…

Average node.js app is slow. It requires godlike understanding/experience to make JS perform well. That why you see people re-writing JS to rust and go and zig, for example SWC, turbopack, esbuild and rome. For most use cases JS is plenty fast but average go code will be faster and easier to maintain.

As I am getting older, I do not want to spend my weekend learning about new features in next.js v13[1]or rewriting tests from enzyme to RTL[2]. I want to use programming language that value its users time and focus on developer experience.

[1] https://www.youtube.com/watch?v=_w0Ikk4JY7U [2] https://dev.to/wojtekmaj/enzyme-is-dead-now-what-ekl

Re: PR that converts the TypeScript repo from namespaces to modules

#86

Post by redox99 »

Chyzwar wrote: post #81
bigyikes wrote: post #39

Earlier quoted context omitted.

Every TypeScript project I have worked on either: 1) enforces no extension, e.g. “utils/foo”, or 2) allows TS extensions, e.g. “utils/foo.ts” I have never imported a TS file using a JS extension. Maybe your woes could be fixed with a configuration change?

No, you were using non-standard ESM modules (compiled to CommonJS defined by babel) Typescript recently added support for ESM compatible with node.js see "module": "node16"[1][2] The Whole ESM saga is clusterfuck, not much better than python 2 -> 3 migration. Large node.js codebases have no viable path to migrate, and most tools still cannot support ESM properly[3]. Stuff is already breaking because prolific library…

Yeah it's pretty ugly. This whole thing is a prime example of those cases in which maintainers for mostly arbitrary reasons decide on something and then absolutely ignore all the massive negative feedback they get for this.

They'll cite some nebulous technical reasons of why it has to be this way, but if you offer a PR that actually solves the issue that the community complains about, they'll reject it.

In this case they decided that tsc won't transpile imports. They just did and it's "policy" and it can't be changed. It doesn't matter if it is awful for compatibility, developer experience, etc. It's just the policy. Issues will be closed. And no, even an optional flag to transpile imports is off the table, even if you write the PR for it.

There are many many issues opened related to this in github, but to give an example

https://github.com/microsoft/TypeScript/issues/16577

Re: PR that converts the TypeScript repo from namespaces to modules

#87

Post by tryfinally »

throwup wrote: post #83
CodeWriter23 wrote: post #52

Earlier quoted context omitted.

> Why not save even more bytes and re-format the output to single tab indentation? For your answer search "programmers who use spaces make more money"

I wish they had broken down that survey question further to find out _how many_ spaces the highest paid developers use. Then I could finally have a data-driven answer to put in my prettier config!

Surely, on average, it's 3 spaces of indentation. Feels great to finally be able to derive objective answers to these ages-old conundrums!

Re: PR that converts the TypeScript repo from namespaces to modules

#88

Post by lmohseni »

jdrek1 wrote: post #58
CodeWriter23 wrote: post #52

Earlier quoted context omitted.

> Why not save even more bytes and re-format the output to single tab indentation? For your answer search "programmers who use spaces make more money"

Correlation != causation Spaces are simply inferior to tabs since the latter conveys the meaning of "one level of indentation" while the former does not. It's also better for accessibility and file size. There is not one single logical reason to ever use spaces for indentation, not one. For some very fucking stupid historical reason someone in the 80s made the idiotic decision of spaces being the default in editors a…

Also for blind programmers, tabs are much nicer for a screen reader.

Re: PR that converts the TypeScript repo from namespaces to modules

#89

Post by bnt »

robbick wrote: post #63
zebracanevra wrote: post #29

After this change, the TypeScript compiler will now be compiled with esbuild. I feel like thats probably the best endorsement esbuild could get, hah. Surprising they call out the 2 space indent level that esbuild is hardcoded[1] to use as a benefit. Why not save even more bytes and re-format the output to single tab indentation? I wrote a simple script to replace the indentation with tabs. 2 indent size: 29.2MB, tabb…

I can see this is probably a calm point that will definitely not escalate, programmers don't really care about tabs and spaces that much, right???

Tabs

Re: PR that converts the TypeScript repo from namespaces to modules

#90

Post by jakebailey »

throwup wrote: post #84

Does anyone have any insight about how to coordinate this kind of change to a large project? This kind of change touches literally every file, so every branch will have merge conflicts. The best idea I can think of is to announce the date ahead of time and make every contributor rebase their branches on the day of the merge. But there has to be a better way. > | edit [–] | on: PR that converts the TypeScript repo fro…

Surprisingly, at least for this PR, solving merge conflicts turns out to not be too hard. By not squash merging it, we can have a single commit that unindents the codebase all in one go (and the commit is in the tree), which means that every line has a clear path back to the current state of the main branch. (And crucially, we can make git blame not point every line to me...)

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.

Post reply on HN