Repository navigation
Resolve tsconfig.json extends path using node_modules resolution logic #18865
Description
Activity
Seems like a good idea. If this feature is added, I think it would be important that it also work with
"paths".Maybe this would be a small
step toward Project References 😉We excluded it during the initial implementation due to complexity, but left an error for it in so we could go back and add it later if we needed to. An issue here is that the module resolution strategy we use is determined by your compiler options... and an
extendsoption can be specifying just what that module resolution scheme is, which is kind of a circular dependency - you must know your module resolution scheme to resolve anextendsoption, but yourextendsoption can lead to where you specify some module resolution scheme!Reacted by Aluan Haddad, Bob Myers, Nash Spence and Nicholas JamiesonReacted by Aluan HaddadReacted by Aluan HaddadReacted by Anton GilgurWesley Wigham (@weswigham) yeah that is paradoxical 😨. We find the source of truth only to learn from it that we were never meant to discover it...
Reacted by Matt and s4m0r4m4Reacted by Ersin AkinciHow about escaping the paradoxical loop by just letting Node.js resolve this as it normally would?
BTW, for reference and inspiration, all of these support resolving this to a package export:
Reacted by Sindre Sorhus, Esteban Martini, Pelle Wessman, Boris Serdiuk, Felix Becker, Nate Ryall, Matt, Burkhard Reffeling, Olzhas Alexandrov, Dieter Geerts and 2 moreHow good of an idea would it be to use
"extends": "./node_modules/typescript-config-foo/index.json"until this is possibly implemented?Reacted by Burkhard ReffelingReacted by Olzhas Alexandrov, jfdesgagne, Roe Greene and Valentin Gurkovmightyjam that's a relative path, so it's fine.
How about escaping the paradoxical loop by just letting Node.js resolve this as it normally would?
We do not always use node module resolution for your package (you have to specify in your configuration if you want node module resolution or a custom scheme - that's effectively what
"moduleResolution": "classic"is), and it stands to reason that we'd use the same module resolution for your configuration as for your other files. Which leads to the issue that it becomes possible to not know what module resolution scheme to use to find your configuration until we have found your configuration, which is an issue.Reacted by Aluan HaddadReacted by Olzhas Alexandrov and Dieter GeertsThe solution can be something like setting the
moduleResolutionin the "children":{ "extends": "external-package/tsconfig", "compilerOptions": { "moduleResolution": "node" } }And, if the
external-package/tsconfig.jsonfile also have amoduleResolution, then you throw an error like:'moduleResolution' can't be overwritten because 'external-package/tsconfig' is already setting a value. And, if not, then you resolve trough the node resolution.This right now is a "blocker" for me, because I have a "core" module with the settings that will be shared among all my modules, and because the path is relative to node_modules, and npm has now a flat tree, this breaks.
For now I'm resolving it by adding setting the value to
../external-package/tsconfiginstead of./node_modules/external-package/tsconfig, but this solution is dirty because in development I need to have the core module one level above the module I'm working on in order to make it work.TSLint already have this resolved, you can make something like the example above without any issues.
Yup. I'm the same use case as Luke Shiru (Legacy) (@lukeshiru).
I can't imagine why the node_modules being flat prevents you from resolving properly, Luke Shiru (Legacy) (@lukeshiru). I don't understand what you're doing there. Why do you resolve other than what my example shows?
tsconfig.json is not used after package is packaged, right? So my workaround should work.
How good of an idea would it be to use "extends": "./node_modules/typescript-config-foo/index.json" until this is possibly implemented?
Not a very good idea. In my mono-repo setup, the plan would be to have a config-like sub-repo, and it could end up getting put at a higher level, so you'd need to do
../node_modules/@myproject/config/tsconfig.json, essentially guessing whereyarnwould put things, which is exactly why I suggested some way to follow the built-in node module resolution algorithm.Reacted by Lou Cyx, Frank Wallis, Mathis Wiehl, James Ravenscroft, Felix Becker, Burkhard Reffeling, Olzhas Alexandrov, Chad Ostrowski, Sang Dang and romdejLuke Shiru (Legacy) (@lukeshiru) there is always a
--moduleResolution, but it is often implied.
--module commonjsimplies--moduleResolution node, otherwise the language defaults to--moduleResolution classic.Shahar "Dawn" Or (@mightyiam) the problem is mentioned by Bob Myers (@rtm). Let's say you have you children module using the parent's module config like this:
children-module/tsconfig
{ "extends": "./node_modules/parent-module/tsconfig" }If you then, have that children module used somewhere else (let's calle it
other-children-module), that reference becomes invalid, because instead of having this:children-module/ └── node_modules/ └── parend-module/Now you have this:
other-children-module/ └── node_modules/ ├── children-module/ └── parent-module/The flat dependency tree makes children and parent at the same level. So for that to work you need children-module to have the config changed to:
{ "extends": "../parent-module/tsconfig" }The ideal scenario should be to solve it like TSLint does, by setting it like this:
{ "extends": "parent-module/tsconfig" }And letting node resolve it.
Reacted by Burkhard Reffeling, Olzhas Alexandrov and Valentin GurkovAluan Haddad (@aluanhaddad) that still doesn't solve the issue. See my comment above for clarification.
Although by no means the only use case, the requirement might be simplest to understand by looking at the case where I want to install some config globally:
npm install --global cool-tsconfigsThen use it by saying
"extends": "cool-tsconfigs/tsconfig.test.json"Reacted by George Yong, Olzhas Alexandrov, iulo and Sergey Rotanev15 remaining items
Hey Wesley Wigham (@weswigham)! I think that PR didn't fixed this issue. I have a repo with settings and I'm trying to extend them like this:
// child-module/tsconfig.json { "extends": "@org-name/settings-repo/tsconfig.json" }
And instead of looking for it in the
node_modulesdirectory, it looks for it in the cwd, which is not the expected behavior. If I use this instead:// child-module/tsconfig.json { "extends": "./node_modules/@org-name/settings-repo/tsconfig.json" }
It will break because that only works in this scenario:
child-module/ └── node_modules/ └── @org-name/settings-repo/But then if I use
children-moduleit breaks in this scenario:other-module/ └── node_modules/ ├── child-module/ └── @org-name/settings-repo/Because is not anymore in
child-module/node_modules, instead it is inchildren-module/... You are forgetting about plain structures...Reacted by pwentz, Adam Charron, Cristian Pallarés, Jeff Principe, Nick Fields, Daniel Hillmann, Eris, Romain Faust, Justin Abene, TidyIQ and 1 moreReacted by Anton GilgurWesley Wigham (@weswigham) Any chance this could be re-opened. As Luke Shiru (Legacy) (@lukeshiru) points out this hasn't been properly implemented. The current implementation is not in line with the described Module resolution
nodein the typescript documentation.Reacted by Burkhard Reffeling, Jeff Principe, Eris, Nk, Romain Faust, Phil Rajchgot and Olzhas AlexandrovLuke Shiru (Legacy) (@lukeshiru), Adam Charron (@charrondev), please allow me to suggest that opening a new issue might help. You know how no-one likes reopening closed issues.
I am confused by this reported "bug" because I have been using this feature extensively since it was implemented and it works exactly as expected. Perhaps something else is wrong in your case. You may need to provide more information or even a sample repo.
This definitely work properly for me at this point on
3.4release in most scenarios.I'll try to put together my reproduction case soon though. It's something like the following:
- ~/workspace/oss-core/ - ~/workspace/oss-core/tsconfig.json (extends `@vanilla/tsconfig/core.json`) - ~/workspace/oss-core/plugins/proprietary-plugin (symlink to other directory). - ~/workspace/proprietary-plugin - ~/workspace/proprietary-plugin/tsconfig.json (extends `@vanilla/tsconfig/core.json`)In this file structure I would expect the tsconfig extension to be capable of being discovered from when looked at through the symlinked file.
Instead
oss-core/tsconfig.jsonworks, butproprietary-plugin/tsconfig.jsondoes not.I think that the real file path is being resolved before evaluating the config file. I believe this is similar to the issue Luke Shiru (Legacy) (@lukeshiru) is describing, but slightly different.
In any case I can open a separate issue and try to make a sample repo for my issue.
I'm not sure how people are saying this works... My project structure is like so:
parent /project /tsconfig.js /node_modules /@package /tsconfig.jsAnd contents of `parent/project/tsconfig.json is:
{ "extends": "@package/tsconfig.json" }Yet it fails as it's trying to extend from
parent/node_modules/package/tsconfig.jsoninstead of fromparent/project/node_modules/package/tsconfig.json. Why is it looking for node_modules in the parent of the root instead of root itself?Reacted by Russell Dempsey, Dieter Geerts, Abdullah Hilson, Cameron Flint, 정석호, Liam, Valentin Gurkov, Onur Fesci and Jimmy MultaniI also can confirm that this just doesn't work. Going through the code of that PR, I can only find out that the internal code is just over engineered and complicated for no apparent reason. Why is just doing
requirenot an option here and just let node do his work?I also want to note that it doesn't work by just doing:
"extends": "@company/config-typescript"Why am I trying this? Because I want to have an
.jsfile where I can dynamically build the config depending on the project extending it.We don't support any kind of .js based configuration. At all. You should just have a tsconfig.json in the package root, which, ofc, can't do anything dynamic.
Reacted by Moshe Brevda, Thomas, kdevan, Max, Dieter Geerts, Cristopher, Rodrigo Roa Rodríguez, Than Hutchins, Ashkan Pourghasem, Sabarni Das and 6 moreWe don't support any kind of .js based configuration. At all. You should just have a tsconfig.json in the package root, which, ofc, can't do anything dynamic.
would such things be on the roadmap? As mono-repos are used more and more, it is useful to share config with the same includes following the globs that all projects inside the mono repo complies to and have dynamic things in it.
For example, we do this with our babel and nyc config, and that works like a charm.
Go open an issue - #30400 kinda tracked it but was closed by the author.
I think we should have the same option for the
includefield as well.
I am trying to manage my tsconfigs by keeping them in a repo/subrepo, and was hoping this would work:
But I get
Is there some reason why the path given to
extends, if neither relative nor absolute, could not be searched for using thenode_moduleslookup rules?(I would also like multiple extends, but I suppose there was some reason for not doing that, and that would be another ticket anyway.)