total-typescript / tsconfig

The simplest way to set up your tsconfig.json
https://www.totaltypescript.com/tsconfig-cheat-sheet
874 stars 17 forks source link

Why DOM and NO-DOM options? #14

Closed GermanJablo closed 2 months ago

GermanJablo commented 2 months ago

I have a version of this repository that is a single file intended to be copied and pasted rather than installed.

I don't know if you've seen it, but I invited you to participate for a couple of PRs. I'm particularly interested in this one:

In the case that the code does not run in the DOM, I don't see any harm in paying for setting: "lib": ["es2022", "dom", "dom.iterable"], even though dom and dom .iterable are not used.

Additionally, it is likely that a project will start with no intentions of being used in the dom and this will change later.

Therefore, in order to reduce the burden of choice on users, this PR moves "lib": ["es2022", "dom", "dom.iterable"] to the base options, as it is a good default configuration.

mattpocock commented 2 months ago

In a word, correctness. It's important that the types reflect the runtime environment.

GermanJablo commented 2 months ago

My confusion arises from the fact that full-stack frameworks execute code in both environments.

Are there any types that exist in both environments and are different?

mattpocock commented 2 months ago

Famously, setTimeout

GermanJablo commented 2 months ago

Well, but you can use window.setTimeout when you're in the browser to set the correct type. Which again, is what you have to do anyway in full-stack frameworks that can run code in both environments.

And even if there were a different case or two, I personally find it more likely to run into an error starting with no-dom and then ending up needing something from the dom.

Personally I'm always going to use "es2022", "dom", "dom.iterable", but that's just my two cents, and I understand your point and if you want to leave it as it is now.