Add default tsconfig.json

[skulptur]

This uses the default tsconfig.json generated with tsc --init (tsc Version 3.9.5).

Only change from that right now is adding
"importsNotUsedAsValues": "error"

[ThaNarie]

Besides the comments, everything else looks good to me:)

[ThaNarie]

Should we include some default libs here, or manage this in our boilerplates? e.g.:

"esnext",
"dom"

[skulptur]

Probably makes sense to have some defaults here. I can imagine not using "dom" when writing libraries, but does having it anyway have any downside?

[ThaNarie]

So we have 2 options:

• leave this default, and require projects/boilerplates to set this explicitly (opt-in)
• include esnext, dom to be future-compatible for most of our use cases, and allow projects to change or opt-out of this setting (opt-out)

Including more by default can only do harm of a project doesn't include all the polyfills for the given version, and developer uses it without testing their code.
But this could also happen if we include es2019 if we need some of the features, but haven't included polyfills for all of them.

Using esnext here means we don't have to update it every year, and kan keep using the newest features combined with babel-preset-env in our projects.

[ThijsTyZ]

I like the 'opt-out' option, but I would suggest the following list:

      "ESNext",
      "DOM",
      "DOM.Iterable",
      "ScriptHost",
      "ESNext.AsyncIterable"

[ThaNarie]

More often than not, I have to explicitly specify types here, since the default will include everything in the @types module folder.

Including everything often gives conflicts due to packages (mostly build-tools) having other types installed as sub-dependencies, that rely on the node environment instead of the web environment.

Not sure if there is something we can do in this file, but maybe some documentation about this common use case could be beneficial.

[skulptur]

We can put this file in a directory with a default type declaration file, and a .md for documentation if needed

[ThaNarie]

We can put this file in a directory with a default type declaration file

What do you mean by this? :)

[skulptur]

That quote I thought you meant adding a .d.ts file, but now I see it's about adding a list that would be tied to a project's dependencies. Correct?

That issue is annoying and I didn't know manually including stuff was the solution. So is there any other way between types and typeRoots to prevent that? Maybe if we identify which common libs we use tend to screw things up that would be a middle ground? Or is this a declare everything vs include everything kind of deal?

[psimk]

I think that we don't need a default tsconfig.json, as it will have to be updated either whenever TS decides to add something or when node upgrades and we need to support a new module or target.

So I would much rather have tsconfig.json's defined in our skeletons, where we can change them when we decided to bump our Node or Typescript versions

[ThaNarie]

So I would much rather have tsconfig.json's defined in our skeletons, where we can change them when we decided to bump our Node or Typescript versions

That's something that should definitely happen.

I think that we don't need a default tsconfig.json, as it will have to be updated either whenever TS decides to add something or when node upgrades and we need to support a new module or target.

I think the main reason for this is "documentation" purposes (and) as a starting point for any other project/library/skeleton that we create.

Maybe instead of a file, we could make it a markdown page, that includes:

• The TS version this is last updated for
• The configs where we explicitly want a certain value, either because of or coding standards / linting (e.g. strict mode, or how we import types)
• And some configs that we set or change most of the times to make them work for certain project types (e.g. moduleResolution, types, etc).

And for the bottom 2, an explanation for why we dictate or advise these settings, to serve as documentation.

@psimk @skulptur how do you feel about that?

[ThijsTyZ]

Do we still need this PR? The tsconfig.json is now part of the Skeletons I assume

[psimk]

@ThijsTyZ
This PR no, but we probably want to turn @ThaNarie's suggestions into an issue & then PR.