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

181–190 of 204 posts

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

#181

Post by matt_kantor »

cush wrote: post #64
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…

Where are you seeing this? The PR that this thread is about doesn't have this quirk. Maybe your setup has some issue...?

Their complaints are unrelated to this specific PR.

See https://www.typescriptlang.org/docs/handbook/esm-node.html for details about how import paths work in CommonJS vs ESM. In both cases the import path you write in your source code is the same import path that is used in the emitted JavaScript. What's different is that NodeJS's ESM implementation doesn't allow extensionless import paths (but its CommonJS implementation does).

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

#182

Post by tantalor »

jakebailey wrote: post #152
nikeee wrote: post #134

Earlier quoted context omitted.

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

> pause merges

That's what I was worried about, but I guess you can't have merge conflicts if you freeze the code.

Suppose you couldn't freeze the code, then what would you have done?

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

#183

Post by kazinator »

spartanatreyu wrote: post #107
robbick wrote: post #63

Earlier quoted context omitted.

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

> The real problem is that using spaces for indentation is an accessibility issue.

The problem of leading spaces not changing their size can be solved through programming.

Those programmers who have such a problem and need leading space to be rubbery, if those programmers are worthy, will solve that problem instead of complaining that everyone should adapt to them.

The use of tabs is detrimental to code bases. Whenever tabs creep in, invariably people use different tab settings and make a dog's breakfast out of the code.

Code exhibits indented sub-structures that are internally indented, but not themselves not aligned to a tab stop, but aligned with something. One kind of example is something like:

  function_name_of_random_length(lambda (a, b) {
                                     if (a

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

#184

Post by shynrou »

z3c0 wrote: post #53
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"

TLDR "Programmers who use spaces are more likely to respond to StackOverflow surveys soliciting information about their income."

That's not how statistics work, unless you assume there is a correlation between tab users salary and their willingness to respond to surveys. Which would also be an interesting find

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

#185

Post by iainmerrick »

conaclos wrote: post #173
iainmerrick wrote: post #105

Earlier quoted context omitted.

That doesn’t look like an issue that’s going to be resolved any time soon. Lots of comments which read like people digging in their heels to preserve the current behavior.

It was in the 4.9 iteration plan [1], and is now in the 5.0 iteration plan [2]. They also talk of this in a design meeting [3] and a member of TS team seems committed to it. [1] https://github.com/microsoft/TypeScript/issues/50457 [2] https://github.com/microsoft/TypeScript/issues/51362 [3] https://github.com/microsoft/TypeScript/issues/51302

Well, I would love to see it, so I hope I’m wrong and you’re right!

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

#186

Post by dotancohen »

gchamonlive wrote: post #178
3836293648 wrote: post #170

Earlier quoted context omitted.

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

Are you visually impaired of have you received or read criticisms of this nature from visually impaired persons? Genuine curiosity, because if this is a matter of accessibility I would vouch for tabs. Thing is that with spaces you can also predict consistently the line length and not have code being clipped on someone's screen that set tabs for 8 spaces for some reason. In any case, I like spaces but I am impartial t…

  > Thing is that with spaces you can also predict consistently the line length and not
  > have code being clipped on someone's screen that set tabs for 8 spaces for some reason.
Spaces force you to worry how that other dev will see the code. Tabs are semantic - you set the editor to display how _you_ like to see it and that other dev sets the editor to display how he likes to see it.

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

#187

Post by Chyzwar »

zarzavat wrote: post #169
Chyzwar wrote: post #110

Earlier quoted context omitted.

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…

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

Performance is affected only during startup by maybe few milliseconds. This is a major breaking change to module resolution made by node.js. Why TS should paper over change that was made by node.js.

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

Some things are supported by tsserver not typescript compiler. Fixing this in TS is only addressing the problem partially and is shifting the problem into tools developers.

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

#188

Post by z3c0 »

shynrou wrote: post #184
z3c0 wrote: post #53

Earlier quoted context omitted.

TLDR "Programmers who use spaces are more likely to respond to StackOverflow surveys soliciting information about their income."

That's not how statistics work, unless you assume there is a correlation between tab users salary and their willingness to respond to surveys. Which would also be an interesting find

I'm curious if you've actually worked with surveys before, because this is how statistics work. All self-reported data has a bias based on a user's willingness to reply, and considering that predisposition as a variable is required.

This is the exact reason that crime statistics are so crummy, even from anonymous surveys. Very few are compelled to admit to a crime that they haven't been convicted of (and some won't even to admit to that). Or why post-sale NPS scores have a negative bent - you're more likely to respond if you have a complaint.

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

#189

Post by bakkoting »

conaclos wrote: post #67
cypress66 wrote: post #49

Earlier quoted context omitted.

And that's how it should work imo. But if you enable esm (which you might need in the future because of packages being esm only) you can't use those, only .js. That's because typescript developers are dead set that they don't want to transpile the imports, they just want to copy paste them into the resulting file when running tsc.

This could change with an ongoing work to allow ts extension [1]. [1] https://github.com/microsoft/TypeScript/issues/37582

You'll only be able to use that if you are using the non-default `--noEmit` configuration, which requires the use of some other tool to strip types. Even after that change, using `tsc` to strip types will still force you to write `.js` in your imports.

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

#190

Post by Dylan16807 »

kazinator wrote: post #183
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.

> The real problem is that using spaces for indentation is an accessibility issue. The problem of leading spaces not changing their size can be solved through programming. Those programmers who have such a problem and need leading space to be rubbery, if those programmers are worthy, will solve that problem instead of complaining that everyone should adapt to them. The use of tabs is detrimental to code bases. Whenev…

Sometimes it can make sense to align arguments but I strongly disagree with pushing over a multi-line lambda that way.

So I'm not convinced the problem you're describing should ever happen.

Post reply on HN