Mechanism for package authors to give auto-import hints

Apologies if this exists and I just couldn't find documentation on it. We have several in-house npm packages to offer common functionality across our codebases. Each of these packages defines subpath exports entries to directly target individual functions and components, in addition to getting everything from the root entry. To use an example with MUI, you can do either of these:

import { Grid } from '@mui/material';

or

import Grid from '@mui/material/Grid'`

The problem is, the auto-import completion rarely even lists the later, just the former, or sometimes, when it does go deeper, it tries to import the direct file (eg, @mui/material/node/Grid/Grid.js) instead of using the subpath export.

It would be very helpful if I, as a package author, could give weight to the exports so that I can tell vscode "this is actually the better path to use for suggesting this export."

Something in the same vein that I've been considering is the ability for package authors to specify a default name for namespace auto-imports (#52527, #23830).

Something in the same vein that I've been considering is the ability for package authors to specify a default name for namespace auto-imports (#52527, #23830).

Oh yes 🙏 this would be super awesome. In a similar vein... some consumers prefer namespace-based imports so it would be cool to have that configurable from the consuming side of things as well.

Is there any reason that you prefer the subpath export?

Hm, I didn't exactly have subpath exports/imports in mind. Just that in some codebases import * as React from 'react' is preferred. It would be cool if auto-importing useState could result in this:

// pre
useStat/*cursor*/

// post
import * as React from 'react'
React.useState/*cursor*/

Mateusz Burzyński (@Andarist)

Sorry Mateusz Burzyński (@Andarist), I meant that more as a question for Jocelyn Badgley (@Twipped).

Daniel Rosenwasser (@DanielRosenwasser)

Wow, I was really confused for a moment there about how this ended up on the typescript repo.

Daniel Rosenwasser (@DanielRosenwasser) Importing from root exports increases overhead in testing and build processes due to increased IO churn and tree-shaking. We actually have a linting rule to prevent importing from several root packages, like @mui/icons-material where the root has HUNDREDS of named exports. We saw a significant reduction in CI execution time after adding that rule to our codebases.

So vscode's auto-import always grabbing the root increases development time, since it immediately gets flagged by eslint.

I sort of wonder if the package itself is the right place for this information. material-ui could have chosen to not ship a barrel, after all, so they're presumably at least somewhat agnostic on the question. For things on DT, this could definitely start some style flame wars as people debate which form is "correct".

Related, it looks like someone's already made a VS Code plugin for this exact situation.

Does #49578 fix this in your project? I'm not sure what the matching rules are but it seems like you could block imports from exactly @mui/material

Ryan Cavanaugh (@RyanCavanaugh)

Ryan Cavanaugh (@RyanCavanaugh) ohh, that might indeed solve it. I'll take a look today

Edit: Unfortunately, this just removes MUI from the auto-import entirely, it doesn't make the deeper file available. Same happens for our own internal libs with subpath exports. The issue seems to be that vscode isn't even seeing those other options.

Material doesn't use subpath exports, they just rely on node-resolution to hit the deeper pathways, so it would seem vscode isn't traversing the exports when deciding what files to offer.

My own utils library does use subpath exports, however, and still has the same result. Like if I type isUndef, the menu offers me three options, and all are targeting the root export. If I block that path using autoImportFileExcludePatterns, the list is just empty.

I figured it out! I can actually solve for this, by defining a typesVersions entry in my package.json.

  "typesVersions": {
    "*": {
      "*": ["./dist/*.d.ts"]
    }
  },

This gets vscode to properly recommend the subpath export instead of the root export. Problem solved!

I figured it out! I can actually solve for this, by defining a typesVersions entry in my package.json.
  "typesVersions": {
    "*": {
      "*": ["./dist/*.d.ts"]
    }
  },
This gets vscode to properly recommend the subpath export instead of the root export. Problem solved!

I'm not sure how that would solve the issue (it doesn't for my case)

I'd love for something like this. I have a package that TS is insisting on importing like:

import { someUtil } from "my-utils/dist/esm"

When I just want

import { someUtil } from "my-utils"

If I use the autoImportFileExcludePatterns setting to exclude the former, it also excludes the latter. Would be nice if autoImportFileExcludePatterns could be a map from bad -> preferred import

Navigation Menu

Repository navigation

Mechanism for package authors to give auto-import hints #53037

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Mechanism for package authors to give auto-import hints #53037

Description

Activity

DanielRosenwasser commented on Mar 1, 2023

Andarist commented on Mar 1, 2023

DanielRosenwasser commented on Mar 1, 2023

Andarist commented on Mar 1, 2023

DanielRosenwasser commented on Mar 1, 2023

Twipped commented on Mar 3, 2023

RyanCavanaugh commented on Mar 3, 2023

Twipped commented on Mar 7, 2023

Twipped commented on Apr 24, 2023

joshjg commented on Oct 19, 2023

WickyNilliams commented on May 28, 2025

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions