Mechanism for package authors to give auto-import hints

[Twipped]

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."

[DanielRosenwasser]

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).

[Andarist]

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.

[DanielRosenwasser]

Is there any reason that you prefer the subpath export?

[Andarist]

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*/

[DanielRosenwasser]

Sorry @Andarist, I meant that more as a question for @Twipped.

[Twipped]

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

@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.

[RyanCavanaugh]

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

[Twipped]

@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.

[Twipped]

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!

[joshjg]

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)