Use package.json exports for AutoImportProvider under --moduleResolution node

[OnkelTem]

Does this issue occur when all extensions are disabled?: Yes/No

• VS Code Version: 1.66.2
• OS Version: Linux Kubuntu 20.04

Steps to Reproduce:

1. npm init -y
2. npm i yargs
3. create a js file and type there: hideBin (it's a function from the yargs module)
4. then open the "Quick fix..." context menu
5. it doesn't contain an import suggestion

[mjbvz]

@andrewbranch hideBin only is picked up once I add an import for import { } from 'yargs/helpers';

Not sure if if this is a bug or expected

[andrewbranch]

Does it get suggested if you use "moduleResolution": "nodenext"?

This is expected. @types/yargs/index.d.ts has no mention of @types/yargs/helpers.d.ts so there’s no reason we would find it before it’s specifically requested. The typings could easily add a reference to it so this would work. However, the package.json exports does list "./helpers" and we should pick that up under nodenext via #47092. We could possibly run that logic even under the older moduleResolution modes, but it’s a little fishy and we would run the risk of picking up files we shouldn’t in packages that ship CJS and ESM side-by-side, for instance.

[andrewbranch]

Actually, I think under --moduleResolution node it would probably be alright to look at package.json exports for auto-importable files as long as we don’t include import in our conditions. This might be a nice experience improvement, but it may apply to relatively few packages for now.

[andrewbranch]

I’ll plan to investigate.

[OnkelTem]

Hi @andrewbranch!

The typings could easily add a reference to it so this would work.

How could they properly do that?

[andrewbranch]

import "./helpers"

[krisdages]

@andrewbranch If exports contains wildcards, hopefully this would support picking up all matching declaration files :)

I have a few libraries in a monorepo whose modules can all be imported individually, and auto import works great in that repo.
It's very cumbersome to use the published packages in another project, though, so this will be a great addition.

If it would potentially cause issues with the declarations of existing libraries, could there maybe be a flag in package.json to enable auto-import for all the declarations in the package?

Side question -- in TS 4.7, when does the types property in exports get used? Does it apply to moduleResolution: node? In the project using the published packages, types for imported subpaths didn't seem to get picked up unless I specified the wildcards in typesVersions.

[andrewbranch]

exports is not used at all unless moduleResolution is node{16,next}. It’s a new feature in Node’s module resolver, after all.

[PabloLION]

Does it get suggested if you use "moduleResolution": "nodenext"?
import "./helpers"

Hi, @andrewbranch I'm facing the same ts(2691) problem when trying to apply the ESM support.

I read the tsconfig docs and thought it could be the problem of moduleResolution.

However after I've installed the [email protected] with yarn add -D typescript@next in the package, and also added it globally with npm install -g typescript@next.
My "./.vscode/settings.json" has: "typescript.tsdk": "$(npm root -g)/typescript/lib" (also tried absolute path, and relative path:"./../node_modules/typescript/lib")
The ts is still complaining "Compiler option 'moduleResolution' of value 'nodenext' is unstable. Use nightly TypeScript to silence this error. Try updating with 'npm install -D typescript@next'."
And the importing *.ts files of ts(2691) was still there.

Could I get some help from you? TIA.

[PabloLION]

Should I start a new issue?

[patroza]

Could I get some help from you? TIA.

Two things I can imagine:

1. VSCode does not respect the setting, and you must open a TS file, then open command menu (e.g on Mac Cmd+Shift+P) and do: TypeScript: Select TypeScript Version... and manually select the workspace version.
2. You are using plugins that don't respect this setting, e.g Vue Vetur / Vue Language Server don't out of the box. like they need a vetur.config with settings: { "vetur.useWorkspaceDependencies": true, }

[andrewbranch]

I think I’ve convinced myself that this isn’t a great idea, as entrypoints in exports are unlikely to be usable by --moduleResolution node correctly. The issue should basically fix itself as we migrate people away from --moduleResolution node (#50152)