Allow ambient module names to be filtered out of auto-imports or something

[ReneZeidler]

Suggestion

🔍 Search Terms

autoImportFileExcludePatterns, exclude auto import suggestions

✅ Viability Checklist

My suggestion meets these guidelines:

• This wouldn't be a breaking change in existing TypeScript/JavaScript code
• This wouldn't change the runtime behavior of existing JavaScript code
• This could be implemented without emitting different JS based on the types of the expressions
• This isn't a runtime feature (e.g. library functionality, non-ECMAScript syntax with JavaScript output, new syntax sugar for JS, etc.)
• This feature would agree with the rest of TypeScript's Design Goals.

⭐ Suggestion

The option autoImportFileExcludePatterns currently works on the package/module (?) level. I can prevent a whole package from being suggested in auto-imports, but I can't exclude only some of the imports in certain subdirectories of that package. This was already mentioned as a caveat in the original implementation of the option (#49578 (comment)).

📃 Motivating Example

As in the comment mentioned above, my issue also comes from date-fns, but for a slightly different reason. The package has a locale module that includes exports for many different two-letter country codes. Those names also happen to conflict with variable names quite often. When typing one of the country codes, I get tons of suggestions from date-fns which appear before the one I actually want:

It's a minor annoyance, but I'd like to exclude those suggestions.

💻 Use Cases

Currently, I can add "**/node_modules/date-fns" or "date-fns" to the autoImportFileExcludePatterns option, which completely removes date-fns suggestions. But then I also lose the suggestions I actually want from the library.

I tried adding "date-fns/locale", "date-fns/locale/**", "date-fns/locale/*.*", but none of those work and result in no suggestions being excluded at all.

[andrewbranch]

The option autoImportFileExcludePatterns currently works on the package/module (?) level. I can prevent a whole package from being suggested in auto-imports, but I can't exclude only some of the imports in certain subdirectories of that package.

It’s the exact opposite of this. autoImportFileExcludePatterns matches against the file name where stuff is declared. The problem is that the exports of date-fns/locale aren’t declared in the directory date-fns/locale. They’re declared in date-fns/typings.d.ts, as is every other submodule in this package:

Because this package declares everything in one file, excluding it is all-or-nothing.

[andrewbranch]

We discussed adding an autoImportModuleExcludePatterns setting that would work on module names as opposed to file names, and there was general support for something like that, but it was pointed out that a glob pattern is probably not the best format for that.

[eps1lon]

Ideally these affordances are given to libraries not just consumers. Libraries can have way more impact than having to teach everybody about custom VSCode settings. Especially since paths may change between versions.

In React, we have react/jsx-runtime, react/jsx-dev-runtime and possibly react/compiler-runtime. None of these files are meant for manual consumption. They only exist for compilers to use. However, there types may now appear in editor suggestions and auto-import. This is especially bad for Fragment which shouldn't come from different modules.

I tried @private, @ignore and @internal to exclude these types from suggestions but none seem to work.

[ssalbdivad]

Wanted to add here that having the ability to exclude auto imports by module name would be a huge help for setups using tsconfig paths or customConditions to allow importing TS source across packages in a monorepo.

Specifically, it would (hopefully) allow import suggestions across packages in a repo like this without also suggesting imports from the package's primary entrypoint, which is a barrel file and should be avoided internally.

I've struggled against this one for a year or so. Any possible solution would be a huge DX improvement!

[RyanCavanaugh]

@ssalbdivad / @eps1lon interesting feedback, thanks. If I'm understanding it right, it sounds like you have sort of opposite use cases, which makes a good case for some kind of configuration on either end.

Specifically, it would (hopefully) allow import suggestions across packages in a repo like this without also suggesting imports from the package's primary entrypoint

Why isn't a file exclusion of ./packages/**/dist/index.d.ts a working fix here? A specifier exclusion seems hard to manage in this setup; you'd be forced to individually list all the top-level packages in your monorepo

[andrewbranch]

There’s a lot more discussion of @ssalbdivad’s issue in #51418, and we were able to figure out a pretty good workaround and some other potential future improvements there. In short, David wanted to exclude ./packages/foo/dist/index.d.ts when editing other files inside foo, but prefers to import from that file when editing files in other packages, and the repo-wide autoImportFileExcludePatterns doesn’t allow for that. One way to achieve the desired behavior would be to exclude specifiers having the pattern foo/.* while enabling a setting to prefer deep import paths whenever possible—both features that don’t currently exist but are under consideration.

The trick was that David’s foo/dist/index.d.ts was actually named api.d.ts, and there is currently a heuristic about files named index that prevents the local-project auto imports from importing from e.g. "../../../index.js", so the workaround was just to rename api to index.

That said, I still think that’s a good example of how filtering module specifiers would pair well with something like preferDeepImportSpecifiers, since you might generally prefer to import from deep subpaths, but want to make an exception for ^lodash/.*$, for example.

[ssalbdivad]

The api.ts => index.ts fix @andrewbranch mentioned was a huge help in this case, but as mentioned on the other issue, that was definitely not something I would have thought to try without his suggestion, so it likely won't help others stuck in the same situation.

Also just to clarify, the purpose of the setup I'm using (similar to those in @colinhacks recent post) is to have types and runtime imports resolve to .ts files in dev, so the aforementioned .d.ts files are just .ts files as far as the editor is concerned.

[gybau]

Would it be possible to also take into consideration excluding a modules exported functions? My specific case is that I have a wrapper on the useImmer library for react which we use exclusively instead of Reacts useState. Therefore to simplify the dx we export this wrapper as useState. We always have two suggestions and the one from react will always be imported by the auto-import feature. Would it be possible to exclude the original useState from @types/react/index.d.ts but keep all the other imports like useEffect etc.