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

161–170 of 204 posts

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

#161

Post by dotancohen »

gchamonlive wrote: post #124
jdrek1 wrote: post #58

Earlier quoted context omitted.

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…

Spaces define by themselves the spacing convention unambiguously, whereas tabs is environment dependent and need other tools like editorconfig to guarantee consistency

Thats the point.

I like four character width indentation. Linus prefers eight. With tabs VIM shows me what I like and shows Linus what he likes.

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

#162

Post by alangpierce »

KingOfCoders wrote: post #156
RyanCavanaugh wrote: post #13

Earlier quoted context omitted.

Sucrase is written in JS and boasts the highest line throughput of any competing transpiler https://github.com/alangpierce/sucrase Time Speed Sucrase 0.57 seconds 636975 lines per second swc 1.19 seconds 304526 lines per second esbuild 1.45 seconds 248692 lines per second TypeScript 8.98 seconds 40240 lines per second Babel 9.18 seconds 39366 lines per second

"Tools run in single-threaded mode without warm-up." Ithought it was 2022. I have a 12 core machine and my next machine will probably have 22 cores. But I'm amazed, transpiling 636975 lines in [Edit] What I do not understand is "Sucrase does not check your code for errors." So it's not a type checker? Or does it check type errors? Why would I used it for Typescript when the reason to use TS is to add types to JS to p…

Like any transpiler, Sucrase can be run in parallel by having the build system send different files to different threads/processes. Sucrase itself it more of a primitive, just a plain function from input code to output code.

> What I do not understand is "Sucrase does not check your code for errors." So it's not a type checker?

That's correct, Sucrase, swc, esbuild, and Babel are all just transpilers that transform TypeScript syntax into plain JavaScript (plus other transformations). The usual way you set things up is to use the transpiler to run and build your TS code, and you separately run type checking using the official TypeScript package.

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

#163

Post by tobyhinloopen »

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, it’s new, to comply with new stuff from nodejs.

You can likely change it with a config, but do note that importing using .js will be the new standard way of doing things and by changing it through configuration you’re chosing to not follow the new standard.

It’s a complete mess IMO. Every project uses a different way to handle modules and there’s a lot of rough edges.

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

#164

Post by tobyhinloopen »

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…

Elixir + Phoenix is so much better :) we have some apps running in production, some are 6 years old.

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

#165

Post by presentation »

iainmerrick wrote: post #99

A little while ago I asked ( https://news.ycombinator.com/item?id=33051021 ): I’m curious, how many people are using TSC only for type-checking, and a different system (eg esbuild or ts-node) to actually compile/bundle/execute their code? Looks like my suspicion was correct; not even tsc uses tsc!

Probably the majority since popular frameworks like NextJS do it with SWC now.

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

#166

Post by adolph »

Beltalowda wrote: post #136
sublinear wrote: post #133

Earlier quoted context omitted.

> If you had used tabs, changing the tab size would make it align all wrong. This is clearly false. You said this after giving a perfect example of how it's done with tabs.

So you are saying that using a tabstop of eight to align this: -------->coolFun(arg1, -------->------->arg2) Would still look nicely aligned with a tabstop of 4? and 2? Clearly that will not look right.

To understand tabstops properly, you need to throw away the "They always expand to N spaces." idea. If you have access to a mechanical typewriter with tabstops, then go and look at how it works (with tabs being set by protruding pins on the carriage). Tabstops in terminals in the Unix and Linux worlds work this way.

https://superuser.com/questions/710019/why-there-are-11-tabs...

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

#167

Post by masklinn »

notriddle wrote: post #65
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…

Yes, you technically can write high-perf JavaScript code... https://github.com/alangpierce/sucrase/blob/153fa5bf7603b9a5... But freaking SIGH I don't want to. I prefer coding in environments that don't require unrolling loops by hand.

There was a back and forth on that subject a few years back: Mozilla rewrote their sourcemap parser from JS to naïve Rust (/WASM) for a 5.89x gain, mraleph objected to the need and went through an epic bout of algorithmic and micro-optimisations to get the pure JS to a similar level, then the algorithmic optimisations were reimported into the Rust version for 3x further gain (and much lower variance than the pure JS).

https://hacks.mozilla.org/2018/01/oxidizing-source-maps-with...

https://mrale.ph/blog/2018/02/03/maybe-you-dont-need-rust-to...

https://fitzgeraldnick.com/2018/02/26/speed-without-wizardry...

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

#168

Post by SuchAnonMuchWow »

dotancohen wrote: post #161
gchamonlive wrote: post #124

Earlier quoted context omitted.

Spaces define by themselves the spacing convention unambiguously, whereas tabs is environment dependent and need other tools like editorconfig to guarantee consistency

Thats the point. I like four character width indentation. Linus prefers eight. With tabs VIM shows me what I like and shows Linus what he likes.

How do you work with max-char-per-line limits of coding conventions ? Does code you write with tabs as 4 spaces follow the convention but then break on Linus computer ?

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

#169

Post by zarzavat »

Chyzwar wrote: post #110
iainmerrick wrote: post #104

Earlier quoted context omitted.

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 i…

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. T…

TS can already perform complicated refactorings, such as renaming all imports in a project when you rename a file in vscode. So they definitely have all the information they need already.

Node requiring the .js is more understandable, as that actually affects runtime performance: if the name isn’t fully qualified in source then node needs to stat() more paths during resolution.

> What if typescript is running in deno/bum or wasm?

Every TS project already needs a tsconfig.json to specify what permutation of module system configurations it is using.

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

#170

Post by 3836293648 »

ahungry wrote: post #130
gchamonlive wrote: post #124

Earlier quoted context omitted.

Spaces define by themselves the spacing convention unambiguously, whereas tabs is environment dependent and need other tools like editorconfig to guarantee consistency

Well stated.

No, it's incredibly stupid and is missing the point. You use tabs to not be consistent. So that the crazy js person can have a 2-wide indent and the slightly visually impaired person can have an 8-wide indent without reformatting the entire codebase
Post reply on HN