Resolve tsconfig.json extends path using node_modules resolution logic

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.)

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

Wesley Wigham (@weswigham)

Wesley 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...

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:

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

mightyjam

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.

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.

Luke Shiru (Legacy) (@lukeshiru)

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

Luke Shiru (Legacy) (@lukeshiru)

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

Shahar "Dawn" Or (@mightyiam)

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.

Aluan Haddad (@aluanhaddad)

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

Then use it by saying

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

Wesley Wigham (@weswigham)

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_modules directory, 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-module it 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 in children-module/... You are forgetting about plain structures...

Wesley Wigham (@weswigham)

Wesley 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 node in the typescript documentation.

Luke Shiru (Legacy) (@lukeshiru)

Luke 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.

Luke Shiru (Legacy) (@lukeshiru)

This definitely work properly for me at this point on 3.4 release 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.json works, but proprietary-plugin/tsconfig.json does 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.js

And 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.json instead of from parent/project/node_modules/package/tsconfig.json. Why is it looking for node_modules in the parent of the root instead of root itself?

I 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 require not 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 .js file 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.

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.

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.

refactor: use yarn workspaces for easier install

I think we should have the same option for the include field as well.

Navigation Menu

Repository navigation

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

15 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Resolve tsconfig.json extends path using node_modules resolution logic #18865

Description

Activity

aluanhaddad commented on Oct 1, 2017

weswigham commented on Oct 1, 2017

aluanhaddad commented on Oct 1, 2017

mightyiam commented on Oct 20, 2017

mightyiam commented on Oct 20, 2017

weswigham commented on Oct 20, 2017

loucyx commented on Oct 25, 2017

mightyiam commented on Oct 26, 2017

rtm commented on Oct 26, 2017

aluanhaddad commented on Oct 26, 2017

loucyx commented on Oct 26, 2017

loucyx commented on Oct 26, 2017

rtm commented on Oct 26, 2017

15 remaining items

loucyx commented on Jan 21, 2019

charrondev commented on Feb 28, 2019

mightyiam commented on Jun 10, 2019

rtm commented on Jun 10, 2019

charrondev commented on Jun 10, 2019

TidyIQ commented on Jun 19, 2019

dietergeerts commented on Oct 17, 2019

dietergeerts commented on Oct 17, 2019

weswigham commented on Oct 17, 2019

dietergeerts commented on Oct 17, 2019

weswigham commented on Oct 17, 2019

LinqLover commented on May 4, 2021

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions

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