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

71–80 of 204 posts

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

#71

Post by ddoolin »

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…

Tabs are denoted by arrows and I don't like being told what to do! :)

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

#72

Post by ElijahLynn »

TOGoS wrote: post #57
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…

This was actually a significant issue in a large PHP codebase I used to work on. Client hired a new guy who insisted that we convert everything to spaces, and suddenly it took about twice as long to check the thing out from Subversion.

That doesn't make sense that spaces vs tabs would result in a 2x longer checkout. Something else is at play if that is the case.

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

#73

Post by cypress66 »

lewisl9029 wrote: post #56
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…

Agree completely. It also makes interop between Node and Deno more painful. But there is hope on the horizon. :) See https://github.com/microsoft/TypeScript/issues/37582 which is referenced in the 4.9 Iteration Plan as "Support .ts as a Module Specifier for Bundler/Loader Scenarios": https://github.com/microsoft/TypeScript/issues/50457

But that doesn't seem like it would fix the typical flow, there still would be no transpiling of imports. So yes you could use .ts in ts-node, but you would have to use .js in tsc. Which is pretty awful (you want your code to work with both).

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

#74

Post by kuramitropolis »

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…

A thousand times this. It's not only the dumbest thing I've seen a programming language do, it's also dumbest thing I've seen in the JS ecosystem. Ended up having to implement an AST-based post-processor to fix packages before publishing them.

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

#77

Post by noduerme »

TOGoS wrote: post #57
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…

This was actually a significant issue in a large PHP codebase I used to work on. Client hired a new guy who insisted that we convert everything to spaces, and suddenly it took about twice as long to check the thing out from Subversion.

Someone who comes onto a project and actually wants to charge money to sit there and convert tabs to spaces or vice versa. Incredible.

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

#78

Post by camjohnson26 »

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…

English is a bad convention too but we use it because humans don’t need the theoretically best systems to be productive, they need something good enough. Spaces are good enough, tabs are good enough, and anybody who gets emotionally invested in one vs. the other is wasting time.

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

#79

Post by satvikpendem »

speedgoose wrote: post #6
KingOfCoders wrote: post #3

Quoted post unavailable.

I think tooling of one programming language should be written in the programming language. Otherwise the community will hardly be involved. All these rust tools may be slight faster, but typescript developers will not learn rust to improve the typescript compiler.

> but typescript developers will not learn rust to improve the typescript compiler.

Why not? TS has much more in common with Rust than with JS, in terms of typing. Compiler engineers are not that prevalent in the community, but they are much more prevalent in the systems engineering world which Rust is a part of, so I'd assume it's actually more beneficial to have a compiler in Rust than in TS because it would mean more people interested in contributing.

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

#80

Post by wombatpm »

ElijahLynn wrote: post #72
TOGoS wrote: post #57

Earlier quoted context omitted.

This was actually a significant issue in a large PHP codebase I used to work on. Client hired a new guy who insisted that we convert everything to spaces, and suddenly it took about twice as long to check the thing out from Subversion.

That doesn't make sense that spaces vs tabs would result in a 2x longer checkout. Something else is at play if that is the case.

He did mention it was subversion
Post reply on HN