Skip to content

Type imports not taking "exports" of package.json into account #49971

Closed
@KnorpelSenf

Description

@KnorpelSenf

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:

{
    "name": "foo",
    // ...
    "exports": {
        "./types": {
            "types": "./out/types.d.ts"
        },
        ".": {
            "types": "./out/index.d.ts",
            "default": "./out/index.js"
        }
    }
}

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:
screenshot
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.

Metadata

Metadata

Assignees

Labels

Needs InvestigationThis issue needs a team member to investigate its status.

Type

No type

Projects

No projects

Relationships

None yet

Development

No branches or pull requests

Issue actions