tsconfig IDE support for multi project workspace

[andreyan-andreev]

🚀 Feature request

Command (mark with an x)

• new
• build
• serve
• test
• e2e
• generate
• add
• update
• lint
• extract-i18n
• run
• config
• help
• version
• doc

Description

see above.

The problem I encountered is that I was not able to use paths configuration in tsconfig, the compiler works but the ide cries.

Describe the solution you'd like

Add tsconfig.json file at the application directory

Example:

{
  "extends": "./tsconfig.app.json",
  "include": ["src/**/*"]
}

• The "include": ["src/**/*"] I have to add because new files were not picked up by tsserver, something about "the file is not part of tsconfig project" etc.

[alan-agius4]

Hi @andreyan-andreev,

There is already a tsconfig.json at the root level of the workspace which is used by the tsservers and IDEs.

[andreyan-andreev]

Hi @alan-agius4,
your statement is correct. But there is a need to have one in the application directory, the one that is under projects.
./projects/app1/tsconfig.json that extends ./projects/app1/tsconfig.app.json as the last one is not read by the ide and configs like paths are not understood by the ide and the imports are red.

[alan-agius4]

I think that in the case the extends should be different, since I am assuming that you also want to paths to be available in your spec files as otherwise from the spec files certain "virtual" modules will not be able to be resolved.

Hence, the hierarchy of tsconfigs should be more like the below, were the application specific path mappings are defined in project/app/tsconfig.json.

tsconfig.json -> project/app/tsconfig.json -> project/app/tsconfig.app.json
tsconfig.json -> project/app/tsconfig.json -> project/app/tsconfig.spec.json
tsconfig.json -> project/app/tsconfig.json -> project/app/tsconfig.server.json

That being said, I don't think that the Angular CLI should generate the mentioned TypeScript configuration for a number of reasons;

2. A lot of users don't want to use path mappings to have shorter imports, which makes this file redundant.
3. Adding a new file would invalidate a number a courses and learning material.
4. Path mappings are not understood and not supported using certain schematics such as ng generate component and ng generate module etc..
5. In general we want to reduce and not increase the number of files we generate, in this case I think it's acceptable if you want to use path mappings for non design time resolutions, you may need to adjust the project slightly.

Personal observation, in general I'd stick to path mappings purely for design time resolution as intended by the TypeScript compiler and not for runtime which would always require a bundler like Webpack to be configured and thought how to interpret those mappings to make your JavaScript output runnable.

[andreyan-andreev]

Look, I am no expert in typescript or its configuration magic, all I am saying is that angular is doing something fundamentally wrong by using a non standard tsconfig filename to solve its own problems, this creates a issue for the developers because their ide is behaving differently than the angular compiler. Basically the IDE does not care what you or I think, it looks for a specific file. The paths was just an example where this becomes very visible, it is a very popular feature that is widely used. I agree with you that you should have less files rather than more, but angular should have thought about that before adding two files (app.json and spec.json) instead of keeping the standard one. As I said, I am no expert in anyway, maybe there are other solution to this problem that does not involve adding files, I just dont know it, either way this needs to be sorted out somehow.

[alan-agius4]

There are multiple TS configurations (spec.json, app.json, worker.json, server.json) because each of them represent a different compilation unit with its own set of compilerOptions, types and libs. Therefore, replacing these with a single one wouldn't yield the correct behaviour.

We do provide a root level tsconfig.json which is used by the IDE's which does provide a very close experience between the compiler and the tsserver, but indeed this doesn't tackle the application level paths issues in case you are using a monorepo style workspace.

To keep all configuration files named tsconfig.json, one would need to change the folder structure from feature based to type based.

Something like the below

|- src
|-- worker
|---- tsconfig.json
|---- worker1.ts
|-- server
|---- tsconfig.json
|---- app-module.ts
|-- browser
|---- tsconfig.json
|---- app-module.ts
|---- app-component.ts
|-- specs
|---- tsconfig.json
|---- app-module.spec.ts
|---- app-component.spec.ts

The true resolution for this is to use "solution style tsconfigs", which we did back in version 10, but following a discussion with the TypeScript team we decided to roll back until several issues that impacted DX were resolved. You can read more about this here: microsoft/TypeScript#39632