Resolve tsconfig.json `extends` path using node_modules resolution logic

[rtm]

I am trying to manage my tsconfigs by keeping them in a repo/subrepo, and was hoping this would work:

{
  "extends": "my-config-repo/tsconfig.standard",
   "compilerOptions": { }
 }

But I get

tsconfig.json(2,14): error TS18001: A path in an 'extends' option must be relative or rooted, but 'my-config-repo/tsconfig.standard' is not.

Is there some reason why the path given to extends, if neither relative nor absolute, could not be searched for using the node_modules lookup 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.)

[aluanhaddad]

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 😉

[weswigham]

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 extends option 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 an extends option, but your extends option can lead to where you specify some module resolution scheme!

[aluanhaddad]

@weswigham yeah that is paradoxical 😨. We find the source of truth only to learn from it that we were never meant to discover it...

[mightyiam]

How 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:

• ESLint: https://eslint.org/docs/user-guide/configuring#extending-configuration-files
• TSLint: https://palantir.github.io/tslint/usage/configuration/
• nyc: https://github.com/istanbuljs/nyc#publish-and-reuse-your-nyc-configuration

[mightyiam]

How good of an idea would it be to use "extends": "./node_modules/typescript-config-foo/index.json" until this is possibly implemented?

[weswigham]

@mightyjam 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.

[loucyx]

The solution can be something like setting the moduleResolution in the "children":

{
  "extends": "external-package/tsconfig",
  "compilerOptions": {
    "moduleResolution": "node"
  }
}

And, if the external-package/tsconfig.json file also have a moduleResolution, 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/tsconfig instead 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.

[mightyiam]

Yup. I'm the same use case as @lukeshiru.

I can't imagine why the node_modules being flat prevents you from resolving properly, @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.

[rtm]

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 where yarn would put things, which is exactly why I suggested some way to follow the built-in node module resolution algorithm.

[aluanhaddad]

@lukeshiru there is always a --moduleResolution, but it is often implied.
--module commonjs implies --moduleResolution node, otherwise the language defaults to --moduleResolution classic.

[loucyx]

@mightyiam the problem is mentioned by @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.

[loucyx]

@aluanhaddad that still doesn't solve the issue. See my comment above for clarification.

[rtm]

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-tsconfigs

Then use it by saying

"extends": "cool-tsconfigs/tsconfig.test.json"