Use TSConfig bases in npm to reduce the number of TSConfigs in a project

[orta]

🚀 feature request

👋 - hi folks. I got notified that we could probably improve the default template for an angular project using the tsconfig bases repo. A. quick 5m explainer on the project is here.

Disclaimer: I've never built an Angular app, so some of this is from looking at the base template, and I'm not sure how tsconfig's would evolve over time in large projects.

Relevant Package

ng generate's template

Description

TSConfig files can come from NPM, and TSConfig Bases is a DefinitelyTyped-like tool for making them. Today, there are a few recommended bases for frameworks (svelte, react-native, deno etc) and given there are a few angular TSConfigs then I think it could be possible to move them into node_modules.

So for example there could be

• @tsconfig/angular-base
• @tsconfig/angular-test

Which the user's projects can extend from.

[alan-agius4]

Currently extending a tsconfig from node_modules will not work properly with the Angular Compiler.

See: angular/angular#36715

[dgp1130]

Hi @orta, thanks for bringing this up! It's an interesting project to learn about. We talked about this amongst the tooling team and had a few thoughts on the matter.

@tsconfig seems really useful for projects that lack any kind of scaffolding utility (a simple Node script for example) and are not managed by a particular framework or toolchain.

For Angular's case, we already have ng new, which generates all the configuration a user needs. We also support a highly-managed structure, including migrating user code across versions, often including tsconfig.json properties.

If we changed Angular to use @tsconfig/, a couple of the tsconfig files' content could be moved there, though we wouldn't be able to remove the files altogether as they still need to extend the bases. That user benefit is relatively minimal to the structure we already have. It hides some details that may not be important, but also makes it harder for users to follow when it is important.

Even if we did go the route of moving tsconfig files to a dependency package, we would probably ship it under @angular/ or @angular_devkit/ rather than @tsconfig/ just to simplify the release process and so versions could match up more cleanly (for example, v10 projects should link to v10 @tsconfig/ bases). That's the way our .d.ts files are shipped (and recommended by TypeScript) rather than using @types/.

Probably the biggest challenge is that it would complicate migrations. Angular updates user code between major versions to reduce the impact of breaking changes. This would be harder to write and manage if there is an existing configuration inherited from a dependency and more effort to support. It also wouldn't provide any more consistency across Angular applications, because we would still need a tsconfig.base.json just to apply global settings for the project.

As a result of all these points, we don't think it makes sense to have Angular deploy base tsconfig files through @tsconfig/.

• ng new already provides most of the same scaffolding benefits.
• Using @tsconfig/ would not reduce the number of tsconfig files.
• Using @tsconfig/ would arguably make Angular applications' configuration harder to follow.
• If we did put tsconfigs into a separate dependency, it would likely be easier to ship it in @angular/ rather than using @tsconfig/.
• Migrations would be harder to develop and support with the extra layer of indirection.

@tsconfig/ is definitely a cool project, we just don't think it is a good fit for the highly managed nature of Angular applications as they are today.

[orta]

Totally reasonable to me 👍

[angular-automatic-lock-bot]

This issue has been automatically locked due to inactivity.
Please file a new issue if you are encountering a similar or related problem.

Read more about our automatic conversation locking policy.

_{This action has been performed automatically by a bot.}