Repository navigation
Ability to extend compilerOptions's paths config #44589
Description
Activity
There are a number of times something like
"pathsAppend": [], "libsAppend": [], "referencesAppend": [], "includesAppend": []
Where we want to ADD to what ever the default/extended options are, rather than replace/override.Libs being the most annoying even in 'standard' circumstances without extending another tsconfig, but the fact that 'adding' a single lib, REMOVES ALL the default ones added by the "target" setting. And you can't even get a definitive list of what those libs were..
Reacted by Xie Jay, Gustavo Hoirisch, Hadi, rehdie, Julian Jarecki, Dimitri Allegoet, Doug, Nick Bolton, SungHoon Jung, Blake V. and 1 moreXie Jay (@xiejay97) Hi. Did you find a solution or workaround?
Xie Jay (@xiejay97) Hi. Did you find a solution or workaround?
Aram (@ArZargaryan) There is no solution for me yet 😹
+1 This is something very important, what is a workaround for this?
+1. That would be helpful if we could extend the
pathsconfiguration.It seems to me that since the paths are name/value, a simple merge should work, eg:
const new_paths={...basePaths, ...localPaths}The semantics seem quite clear - use the paths in the base config (with resolution relative to that tsconfig file), and merge/overwrite any local ones (relative to the local tsconfig file).
Reacted by Santiago Granada Talenta365 and DevDisignIt seems to me that since the paths are name/value, a simple merge should work, eg:
const new_paths={...basePaths, ...localPaths}jugglingcats where should these be made?
+1 Would really fix stuff in big monorepos
+1 same issue! NX + Remix + NestJS - need local and common paths
Reacted by Lennert Soffers, Ryan Kotzen, orlein, Yona Appletree, Ingrid Kamga, ノア, Marc and Hameed BSSeems this issue was addressed and closed back in 2017 on #14527 due to the suggestion being "more confusing since paths are order dependent and the paths are relative to the baseUrl, and there are two in this case". Which strikes me as an obnoxiously arrogant and dismissive take. Especially considering this can easily be resolved by simply either appending or prepending the base config, and scoping the new paths to either the current config's baseUrl or the base's baseUrl. And considering the increasing need for composite configs with monorepos, this is no longer an edge case (if you could ever argue it was one). Seems like an anti-pattern to suggest we just repeat ourselves in multiple configs.
Reacted by Kirill Agalakov and Santiago Granada Talenta365Folks, there has been an ongoing proposal since November 2023. Let's contribute to the discussion to help get it going: #56436
Reacted by Aram, Ryan Cavanaugh, Eric Lee, Nícolas Gabriel, Bytes, Félix-O, Lennert Soffers, Ryan Kotzen, Alfonso Andrés López Molina, Ruan Heyns and 9 moreReacted by Ryan Cavanaugh, Nícolas Gabriel, Leonardo Pliskieviski, Félix-O, Alfonso Andrés López Molina and Ruan HeynsReacted by Aram, Félix-O and Alfonso Andrés López MolinaReacted by Aram, Félix-O and Alfonso Andrés López Molina+1 here feature needed !
Reacted by Hameed BS, Jaemin Ahn, Paul Berg and x-keyscore+1 here feature needed !
Reacted by Anton KosiakThis is still needed
Reacted by René Bühling
Suggestion
I have a
tsconfig.base.jsonfile for the monorepo, it defined paths that all project can useEach project has own
tsconfig.json, also defined paths that only for itselfUnfortunately, the
pathswould be overwritten.I have to add
tsconfig.base.jsonpaths item to each project.So, it's necessary to provide a solution for this case.
🔍 Search Terms
List of keywords you searched for before creating this issue. Write them down here so that others can find this suggestion more easily and help provide feedback.