[tsconfig] Revisit defaults

[kirbysayshi]

Currently, the target in tsconfig is either es5 or es6, depending on if using the app or lib config. However both of these targets will transpile async/await to tslib's __awaiter fallback (similar to regenerator).

We should be publishing packages that assume a modern, somewhat-evergreen environment, and assume that a library or app is transpiling to older targets if they need to support those targets.

As brought up by earlier discussions when the service config was added, the configs and what should be the default need to be revisited. These options include: target, sourceMap, declaration. Especially now that we have web-scripts in play, which basically handles these.

[kirbysayshi]

Another option here: We should reconsider the app config. Perhaps just rename it to cra for create-react-app. A common issue is that CRA requires skipLibCheck to be true.

[kirbysayshi]

As we've used web-scripts and the tsconfig(s) in various projects. It's become clear that trying to segment tsconfigs by use-case (e.g. app, service, lib) actually causes more complication than benefit. It's also ambiguous. What is an "app", create-react-app? Or is it a babel-powered toolchain? What about target? Do we assume the compiling scripts can handle ESNext? Or ES5?

web-scripts does the orchestration required to emit declarations in a mixed TS/JS project. It already has to override various options related to output (e.g. declaration: false when typechecking to allowJs: true.). This makes it hard to reason about which config values are actually even used in a local tsconfig.

There was an original goal to a shared tsconfig that has become lost along the way: strict typechecking by default to reap as many benefits of TS with as little configuration as possible. Things like noImplicitAny: true by default.

Therefore, to simplify and assert that original goal, I propose:

• we delete all the configs but one and make it the main entrypoint of @spotify/tsconfig.
• in that config, we disable all output options: declaration: false, noEmit: true, etc.
• in that config, we only add options that affect type checking: noImplicitAny: true, strictNullChecks: true, etc.
• major version bump of maybe @spotify/web-scripts and definitely @spotify/tsconfig. I haven't investigated yet; we might be able to get away with a patch version for web-scripts.

[javoire]

I don't have full context but it sounds good! As a user of web-scripts, what would be the migration steps I have to do when upgrading to this? E.g if I wanna keep the current behavior of my project

[kirbysayshi]

Migration depends on if they use web-scripts or not.

• web-scripts users: in their local tsconfig change extend to be the new path: @spotify/tsconfig instead of the removed (app|lib|service).json. We could mitigate this by shipping symlinks/copies of the single config matching the names we ship today.
• standalone tsconfig users: It depends on their workflow. They will likely need to add combinations of either declaration: true and/or noEmit: false depending on if they use babel or tsc, and for what. For example, some apps use tsc as a "lint" step purely for type checking, followed by babel or webpack (with babel under the hood) for transpiling. This change will actually simplify the configs in this case!

We probably need to audit some of the users to fully evaluate the impact.