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

151–160 of 204 posts

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

#151

Post by jtokoph »

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.

Maybe the codebase was one giant index.php file with an average of 20 levels of nested conditionals and open curly braces on a new line.

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

#152

Post by jakebailey »

nikeee wrote: post #134
jakebailey wrote: post #97

Earlier quoted context omitted.

This is as incremental as it really could be; the entire build had to change, all of the code needed to be unindented one level, etc. 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.

I'm curious on how to make such a change in such a large and living code base. Did you consider _not_ re-indenting the entire code base and rely on the auto formatters of contributing people? Did you consider re-formatting parts of the code step-by-step, beginning with code that's not frequently changed? Didn't know about the feature that ignores commits in git-blame, thank you for that.

No formatter would support having code indented like that at the top level for no reason, so that's not an option. Though, I have been looking into getting us to use a formatter, period (right now we don't).

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.

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

#153

Post by bobbylarrybobby »

mathstuf wrote: post #122
spartanatreyu wrote: post #107

Earlier quoted context omitted.

"Tabs vs spaces" is often misunderstood (and falsely reported) as a problem of preference. The real problem is that using spaces for indentation is an accessibility issue. The solution is to use tabs for indentation, and spaces for alignment.

While that may be true, "spaces for alignment" is nigh unsupported by all editors I've seen. They insist on replacing 8 (or N) spaces with tab even if in an alignment region. int foobar(int a, ___________int b) // should only ever have spaces (using _ here because HTML) But good luck finding an editor that won't insert a tab when you use the tab key here (willing to be wrong). The other issue I have is that diffs bre…

Rustfmt, for one, understands how to mix tabs and spaces on the same line. I think the complication is overstated.

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

#154

Post by jakebailey »

idontwantthis wrote: post #150
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…

Does that mean they are not using type checking? That’s the really really slow part of writing TS and es build doesn’t include it, which is why I’ve never seen the point of using esbuild as a compiler.

We are still type checking, it's just not needed as a dependency for our JS outputs. Type checking still happens in tests, and I have CI tasks and VS Code watch tasks which will make sure we are still type checking.

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

#155

Post by mypalmike »

tryfinally wrote: post #87
throwup wrote: post #83

Earlier quoted context omitted.

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!

Average is actually 3.27 spaces, which is what I now set for my tab spacing so as to conform with best practices.

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

#156

Post by KingOfCoders »

RyanCavanaugh wrote: post #13
TAForObvReasons wrote: post #5

Earlier quoted context omitted.

In every single one of these cases, it begs the question whether "JS" is the problem or "backwards compatibility". There are a huge number of inefficiencies that can be fixed with a full rewrite. There was a recent conversation over ViteJS (a pure JS bundler) vs rust-based tooling, and when you dig into the numbers the real difference is SWC vs Babel. It raises the question whether a new transpiler written in JS can…

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 prevent errors?

Is this more like Rust check for continous work and then use tsc from time to time to check for errors?

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

#157

Post by idontwantthis »

jakebailey wrote: post #154
idontwantthis wrote: post #150

Earlier quoted context omitted.

Does that mean they are not using type checking? That’s the really really slow part of writing TS and es build doesn’t include it, which is why I’ve never seen the point of using esbuild as a compiler.

We are still type checking, it's just not needed as a dependency for our JS outputs. Type checking still happens in tests, and I have CI tasks and VS Code watch tasks which will make sure we are still type checking.

Thanks for the reply!

So when your team is compiling locally they don’t type check? It only runs in the IDE and during tests?

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

#158

Post by klodolph »

berkes wrote: post #23
swsieber wrote: post #22

> Finally, as a result of both of the previous performance improvements (faster code and less of it), tsc.js is 30% faster to start and typescript.js (our public API) is 10% faster to import. As we improve performance and code size, these numbers are likely to improve. We now include these metrics in our benchmarks to track over time and in relevant PRs. > [...] > The TypeScript package now targets ES2018. Prior to 5…

I'm curious about that too. From my superficial knowledge of compilers, "modularization" itself should not make code faster, if anything slower. There'll always be some overhead of loading modules and communicating between them, not? I presume, from my own experience when building software (not compilers), that modules allow for a much easier to reason about, much better isolated (cohesion, loose coupling). And there…

> From my superficial knowledge of compilers, "modularization" itself should not make code faster, if anything slower. There'll always be some overhead of loading modules and communicating between them, not?

I think this is a misunderstanding of what actually happened.

TypeScript has a thing called “namespaces” and a thing called “modules”. Both provide modularization. The TS repo is not being modularized, instead, the namespaces are getting converted to modules.

Namespaces are an old-school approach to writing a module in JavaScript. You pack all of your exports into a JS object, and then access the object from somewhere else. This works, but JS is dynamic, and the runtime has no way to guarantee that you won’t mess with this object (replace functions or whatnot).

Modules don’t have this object. You just call the function, instantiate the class, or do whatever else with the names you imported. They are resolved statically, so certain optimizations become more “obvious”, like inlining.

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

#159

Post by jakebailey »

idontwantthis wrote: post #157
jakebailey wrote: post #154

Earlier quoted context omitted.

We are still type checking, it's just not needed as a dependency for our JS outputs. Type checking still happens in tests, and I have CI tasks and VS Code watch tasks which will make sure we are still type checking.

Thanks for the reply! So when your team is compiling locally they don’t type check? It only runs in the IDE and during tests?

It's not perfectly cut and dry, but mostly. We still need to emit d.ts files for our public API, and the only thing that can do that is tsc, which will type check.

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

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

#160

Post by dotancohen »

shadowgovt wrote: post #126
bragr wrote: post #118

Earlier quoted context omitted.

Not everyone with vision or vision processing issues is blind. Being able to configure custom tab stops is an easy way to control what level of indentation is useful and clear.

As with all other types of data: the right approach is for model and presentation to be separable concerns. We're struggling with the wrong problem if we aren't asking why the editor can't treat blocks as entities that are displayed however we want.

  > why the editor can't treat blocks as entities
That might with with C, but won't work with e.g. Python.
Post reply on HN