feat: support local multi target ts projects

[legendecas]

update-ts-references is a great tool for us at https://github.com/open-telemetry/opentelemetry-js to update project references!

However, several targets for a single package can exist in our project. For example, a package can produce 3 different build outputs: 1. default one for Node.js consumers, 2. es5 for browser consumers, 3. esnext with esm for modern browser consumers.

It can be a pain for us to maintain references in each of these targets, as the only difference between them is the compilerOptions.

If update-ts-references can preserve package's local ts config references, we can create an entrypoint tsconfig for update-ts-references to keep track of project's dependencies and split all targets into separate tsconfig files.

See also: https://github.com/open-telemetry/opentelemetry-js/pull/3169

[MKruschke]

Hi @legendecas, first of all, we are happy that you like and use the tool, and thanks for reaching out. 🥳

When I understood the change request correctly you like to reference tsconfig's that are from the same project which is like self-referencing. I personally think that this is something that we should avoid in general.

However, several targets for a single package can exist in our project. For example, a package can produce 3 different build outputs: 1. default one for Node.js consumers, 2. es5 for browser consumers, 3. esnext with esm for modern browser consumers.

We use in our setup also different build outputs. There we have one tsconfig.json in every package which has the projectReferences entry. If we compile for example to esnext, we put the tsconfig.esnext.json also in the same folder and extending from the previously mentioned tsconfig.json and additionally overwrite the compiler options. With that, we only have one file where we need to update/store the project references no matter how many different outputs we like to support.

If you would consider changing your setup to use it similar like we do this would make your tsconfig.all.json obsolete, but I saw that this would mean that you would need to go away from having tsconfigs in for different outputs in your root folder.

I hope that helps you, if not let me know.

Best Mirko

[legendecas]

@MKruschke We use in our setup also different build outputs. There we have one tsconfig.json in every package which has the projectReferences entry. If we compile for example to esnext, we put the tsconfig.esnext.json also in the same folder and extending from the previously mentioned tsconfig.json and additionally overwrite the compiler options. With that, we only have one file where we need to update/store the project references no matter how many different outputs we like to support.

Thanks for sharing your workflow. We have tried this pattern before. The problem we found with this pattern is that we can not compile all targets at once with this pattern. We have to run tsc with each of these tsconfig targets. This can be frustrating at testing and publishing since not all targets are compiled with the default tsc --build. That's why we are referencing all local targets in the project's entry tsconfig.json (as in https://github.com/open-telemetry/opentelemetry-js/pull/3169), so that all targets are compiled with the default tsc --build.

-- project root
|- tsconfig.json (entrypoint, referencing projects' tsconfig.json)
|-- projects
  |- project-a
  |  |- tsconfig.json (entrypoint, referencing dependencies' tsconfig.json, and local targets' tsconfig)
  |  |- tsconfig.default.json
  |  |- tsconfig.esm.json
  |  |- tsconfig.esnext.json
  |
  |- project-b
     |- tsconfig.json (entrypoint)
     |- tsconfig.default.json
     |- tsconfig.esm.json
     |- tsconfig.esnext.json

In this structure, tsconfig.jsons are always the entrypoint and can be used to compile all targets.