Add support for multiple tsconfig paths

[lynch16]

When bundling a monorepo, webpack doesn't know how to resolve conflicting tsconfig paths

package1

• folderA
  1. file1

package2

• folderA
  1. file1
  2. file2

In the above example, if package2.folderA.file2 calls import { foo } from "folderA/file1", tsconfig-paths will resolve the path to package1.folderA.file. The tsc command succeeds b/c TS supports "references" which will bundle projects in a specific order using their respective tsconfig.
tsconfig-paths does not support references
#44
dividab/tsconfig-paths#163

This adds an option for defining "references" so that paths relative to other tsconfig files will be resolved correctly.

[jgornick]

This seems pretty useful! I was going to ask if this plugin could support an array of tsconfig.json paths rather than a single one, but this might solve the issue too with references.

@jonaskello, any thoughts on this?

[jonyw4]

This is a very good addition to the plugin for monorepo scenarios. 👏

I have a situation where a have different alias in different packages and I want to resolve all in the storybook based on the tsconfig. So for now I had to use relatives paths and this is the limitation of the project.

I like the idea that @jgornick gave about adding an array of tsconfig.json as well, maybe we can support that in situations that we don't have references declared.

Also, any reason why this PR is not merged yet? I am very interested in helping add this feature to the plugin if somebody needs help to do it 😁

@jonaskello any thoughts on this PR?

[lynch16]

@jonyw4 @jgornick
I dont understand adding an array of tsconfigs. Typescript expects references for monorepo support so thats how I matched this plugin. It seems odd to have a way to define tsconfigs that TS itself doesn't really support.

[jonyw4]

I see TypeScript references config as the official solution to the problem, and it looks like this PR is solving it. That is awesome, if we could merge it would be great!

But could be nice to have support array of tsconfig for these use cases:

1. In situations where you don't have references configured. (I am working in a project where references are not necessary)
2. To override or extend the tsconfig files paths (as baseUrl do in this plugin, for example, is changing the behavior from tsconfig)

Is just an idea, if that make sense, we could add this as well. If not, it is okay to leave as it is right now. 👍🏻

[lynch16]

The 2nd should already be handled. Extending tsconfigs is a common pattern. Id love to hear about your use case for item 1 though. Do references not meet your needs?

On Sat, Jan 15, 2022 at 9:59 PM Jonathan Célio ***@***.***> wrote: I see TypeScript reference config as the official solution to the problem, and it looks like this PR is solving it. That is awesome, if we could merge it would be great! But could be nice to have support array of tsconfig for these use cases: 1. In situations where you don't have references configured. (I am working in a project where references are not necessary) 2. To override or extend the tsconfig files paths (as baseUrl do in this plugin, for example, is changing the behavior from tsconfig) Is just an idea, if that make sense, we could add this as well. If not, is okay to leave as it is right now. 👍🏻 — Reply to this email directly, view it on GitHub <#79 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AA3BDWCKF4IU4R3IR6RXRB3UWIX7PANCNFSM46XZTF2A> . Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>. You are receiving this because you authored the thread.Message ID: ***@***.***>

-- Will Lynch ***@***.*** 925-330-1622 President and Treasurer Manchester Makerspace ***@***.*** Software Developer Oracle + Dyn ***@***.***

[jonyw4]

TLDR: I could use it, but in my case is not necessary and doesn't solve any problem in my project

Use case example

I can give some context. The project looks like this:

package-1 -> typescript project
package-2 -> nuxt & vue (with typescript, transpiling package 1)
package-3 -> nuxt & vue (with typescript, transpiling package 1)

The idea is that all packages have their own alias. That is fine if you think them isolated, but I am also using Storybook in the root to show all Vue components of both packages. Since all of them have their own alias, storybook (with webpack) is struggling to resolve the alias. So there is the need of this plugin.

About the references

I am neither using build and watch tsc commands (I believe that is one of the main reasons why you want to use reference).
What I am doing is basically building of package 2 or 3 when I require it by running nuxt generate. So references in this case is not necessary.

I think that I can use reference in this case too, just to make this plugin work, but could be nice if this PR support other tsconfig files in situations like this, since not every monorepo setup uses references.

TypeScript docs references usage

Also, I want to point out that I didn't find anywhere in the TypeScript documentation saying that you need to use references in monorepo setup. Since this feature helps in this type of situations, you probably want to use it, but is not mandatory.

[lynch16]

@jonyw4 Why not use references though? Using reference isn't just for build and watch. You'll see the speed improvements using those commands, but more generally, references enforce logical grouping of TS applications. Your project structure seems appropriately suited to references.

I cant really see a reason to create a new pattern of arrays of tsconfig files rather than using the existing reference pattern.

[jonyw4]

I think I cover all the reasons why I am not using the references in the last comment and also a situation where that is not necessary. This is one case, but I am sure that must be other cases as well.

In my situation, I don't mind changing my project to use references, that is fine. I just want to point out that this happens, references is optional, so is good to have a fallback for those situations.

Also, personally, I think that this PR is good to be merged. This feature that I am describing, is an idea to cover those situations. We could do it in the future by the need of other developers.

[jonaskello]

Seems like the consensus is that this is a good feature to add. I'm planning to make a new major release because of #90. @lynch16 Could you add information in the README file about this new option? If possible some tests to cover this feature would be nice too. After that I think we could merge it for release in next major.

[aspirisen]

I think that it is very necessary feature when you have several tsconfig files in separate folders and each of them defines its own paths rules.
Actually vscode resolves paths correctly during development (as i understand it searches for the nearest tsconfig file from what is currently opened in the editor), but you can't use it since there is no option for multiple configs.

[lynch16]

@jonaskello Sorry for the long wait. Updated readme and added a test. LMK what you think

[jgornick]

No need to apologize @lynch16! It's open-source software 😄

Even though it's not my project/PR, thank you for the contribution though!

[jgoux]

Is there any way to move this PR forward? Can I help? 🙏