Cannot extend the "typeRoots" option anymore

[loick]

Bug Report

Adding a common "typeRoots" key on an extended configuration is not taking into account anymore. We discussed it a little bit on this PR: #51715

🕗 Version & Regression Information

it used to work on the v 5.0.4 but it stopped working when I migrted to 5.1.3.

🙁 Actual behavior

I have a global tsconfig json file as following:

// base.json
{
  "$schema": "https://json.schemastore.org/tsconfig",
  "compilerOptions": {
    "typeRoots": ["../../node_modules/@types"]
  }
}

And I'm using it within my monorepo on each package as following:

{
  "extends": "@slowy/config/tsconfig/base.json",
  "compilerOptions": {
    "typeRoots": [ "../../node_modules/@types"]
  },
}

However as you can see, I have to re-declare the typeRoots option which was not necessary before the library update.

🙂 Expected behavior

Being able to extend the typeRoots configuration.

Thanks!

[me4502]

From my testing the extend behaviour does appear to function, however the relative paths are treated relative to the child tsconfig rather than relative to the tsconfig in which it was declared. This does functionally mean it must be included in all child tsconfig files though.

I can't reproduce it with the setup in the issue, but if I create a tsconfig in the repo root with,

{
  "$schema": "https://json.schemastore.org/tsconfig",
  "compilerOptions": {
    "typeRoots": ["./node_modules/@types"]
  }
}

any packages that extend it that are nested in folders don't function unless I add relative typeRoots for each level of nesting,

{
  "$schema": "https://json.schemastore.org/tsconfig",
  "compilerOptions": {
    "typeRoots": ["./node_modules/@types", "../node_modules/@types"]
  }
}

This for example allows packages one directory deep to access types.

[charbelsako]

hello I am having this issue,

I tried importing the file with the typings inside index.ts and it worked

here is my github repo
it's under the branch debuggin-typeroots

[loick]

Hey, sorry for only answering now. I'm still having the issue from time to time (not on all packages, which is why it feels "random"). I still have the same config, but on each package I have an issue with, adding the typeroots to the monorepo root submodule fixes it (even though it's already in my base config).

[ghost]

Having the same issue.

[sheetalkamat]

typeRoots has always been relative to config file its declared in. If you need to override or add locations you always had to define it again in that config file. Earlier we were incorrectly looking into additional locations for "types" resolutions even if you had defined typeRoots and that was the issue recently fixed. So things working before has been unintentional and configuration error. This is working as intended.

[ghost]

@sheetalkamat but in a monorepo case where we have a root tsconfig with typeRoots and projects that only extend it (without add/override), why should it re-declare the same typeRoots relatively?

[sheetalkamat]

You should be setting typeRoots to wherever you are supposed to find types or not setting and let compiler look into default places if the lookups are suppose to happen from node_modules/@types

[ghost]

So in our case, we have a root tsconfig.base.json where we have:
"typeRoots": ["node_modules/@types", "libs/typings"]

Every package extends it (e.g. "extends": "../../../tsconfig.base.json") and does not provide any other typeRoots.
In this case, types are not working as expected. Does this mean every project must specify typeRoots explicitly too?

[sheetalkamat]

Are you expecting types to be present in ["node_modules/@types", "libs/typings"] relative to tsconfig.base.json? if not then yes you would need to override it.

[ghost]

Yes, they are relative to the tsconfig.base.json

[typescript-bot]

This issue has been marked as "Working as Intended" and has seen no recent activity. It has been automatically closed for house-keeping purposes.

[ghost]

Can we reopen it as we're still discussing it?

[sheetalkamat]

@danr-za you can check why the resolution is failing by using --traceResolution option

[ghost]

@sheetalkamat thanks for pointing this out, I was finally able to resolve that. And as you mentioned in your previous comments, older version were probably always looking for types in node_modules regardless of type roots, where we did not provide it and therefore it broke.
Appreciate the help 🙏

[btomaj]

@sheetalkamat to clarify, you're saying that in this setup:

/root/types/*
/root/tsconfig.json
/root/parent/tsconfig.json
/root/parent/child/tsconfig.json

Where in /root/tsconfig.json I have specified:

{
  ...
  typeRoots: ["./types"]
  ...
}

and in /root/parent/tsconfig.json and /root/parent/child/tsconfig.json I have specified:

{
  ...
  extends: "../tsconfig.json"
  ...
}

but not specified

{
  ...
  types: [...]
  ...
}

nor specified

{
  ...
  typeRoots: [...]
  ...
}

you consider it to be working as intended that I get no type resolution in /root/parent/** and receive the following TypeScript error in /root/parent/child/tsconfig.json:

Cannot find type definition file for '...'.
The file is in the program because:
Entry point of type library '...' specified in compilerOptionsts

If so, can you please elaborate on the intention with this design? It boggles the mind.

[sheetalkamat]

Yes this is working as intended because in both tsconfigs (in parent and child) the typeRoot value is coming from your extends clause and it is /root/types so any failure to do type resolution will happen from each value in the typeRoot.

[btomaj]

@sheetalkamat again, to clarify, what happens is that typeRoots: ["./types"] in /root/tsconfig.json resolves to /root/types as expected, but extends: "../tsconfig.json" in /root/parent/tsconfig.json resolves typeRoots: ["./types"] from /root/tsconfig.json to /root/parent/types which makes the inheritance of typeRoots: ["./types"] useless. To confirm, are you saying that this is working as intended? If so, can you please elaborate on the intention with this design? What's the use case?

[sheetalkamat]

The paths specified in config file have always been relative to file in they are defined in so in the parent/tsconfig.json the typeRoot is not /root/parent/types but /root/types

We have been investigating file path inheritance as string and then computing it relative to final config but that is still under investigation and this is current design as it has been always.

[btomaj]

@sheetalkamat I misunderstood you earlier. The current design is logical, is how I would expect it to work. I understand now why you said it is working as intended. Thank you for takin the time to respond and clarify--I've taken the conversation well beyond the original issue.