Current support for @types packages is to just load the base packages into the project. The existing logic handles any dependency types, but is unable to handle types specified by package exports ("exports" field on the package.json).
For example, having the following package.json
{
"dependencies": {
"@types/react-dom": "^18"
}
}
won't produce types for
import {createRoot} from 'react-dom/client';
because only the base @types/react-dom package's index.d.ts is loaded.
In this particular case, a work around was available to add @types/react-dom/client as because they thankfully had a file called client.d.ts that the type resolver ended up adding to the project, and along with the package.json file from @types/react-dom, TS was able to resolve this.
Not sure exactly on best approach to support this.. A naive approach is to crawl the "exports" field of package.json and eagerly load all listed types. Or a smarter approach that handles the extra paths.
Current support for
@typespackages is to just load the base packages into the project. The existing logic handles any dependency types, but is unable to handle types specified by package exports ("exports" field on thepackage.json).For example, having the following
package.jsonwon't produce types for
because only the base
@types/react-dompackage'sindex.d.tsis loaded.It is not able to resolve the
./clientpart from the package exports here: https://unpkg.com/@types/react-dom@18.2.4/package.jsonIn this particular case, a work around was available to add
@types/react-dom/clientas because they thankfully had a file calledclient.d.tsthat the type resolver ended up adding to the project, and along with thepackage.jsonfile from@types/react-dom, TS was able to resolve this.Not sure exactly on best approach to support this.. A naive approach is to crawl the "exports" field of package.json and eagerly load all listed types. Or a smarter approach that handles the extra paths.