Description
Bug Report
The LSP sometimes suggests the wrong paths from which to import types, ignoring the library's "exports"
field defined in package.json
. These imports should neither be allowed nor suggested.
🔎 Search Terms
type import auto-complete exports package.json
🕗 Version & Regression Information
As far as I know, this issue has always existed, since TS starting supporting exports
fields.
⏯ Playground Link
Playground link with relevant code
💻 Code
Let's say that the library's package.json
file contains this:
Note how the library ships its own code along with type annotations for that, as well as some other manually created helper type definitions in a different file. The former can be imported from foo
while the helper types can be imported form foo/types
.
For instance, it is possible to import the type Bar
from foo/types
.
import { type Bar } from 'foo/types'
type X = Bar
🙁 Actual behavior
When I use the type Bar
in my code, the LSP suggests several different ways to add an import statement for that type. However, even though the type Bar
can only be imported from foo/types
(note how no other directory is exposed by the lib), it suggests lots of file paths that all don't make sense.
Here a screenshot where this appears with a library I am maintaining:
Note how the correct path grammy/types
is not even among the suggestions. However, if I use it, it will still work correctly.
It seems like TS allows to import types from paths that are not exported. In contrast, if you try to import things from grammy/out
, it will throw an error at runtime.
It also seems like TS does not always suggest the correct paths, or at least the suggestions are not comprehensive.
🙂 Expected behavior
I would expect TS to also respect the exports
field in package.json
when importing types. That way, users of my library will use the correct import paths to the public interface of the package, rather than rolling with the suggestions from autocomplete which result in type imports to internal files inside the library.