Repository navigation
Exclude specific files from auto import suggestions #35395
Description
Activity
We have a similar issue in a large project: a legacy set of code that no new code should reference but which must stay where it is for compatibility. Being able to instruct VSCode to ignore the files in that folder for the purposes of auto-import would be VERY beneficial.
Currently, we're looking into whether or not ESLint can at least cause an error but I'm not sure it supports restricting relative modules like that.
I would also love to be able to exclude certain files. In my case I need a certain CSS file included AFTER another, however the organizeImports config automatically sorts them in the wrong order.
Reacted by Glandos and Alec LarsonAn additional use case we have is to enable splitting implementation of a large namespace to multiple module files but still expose it under a single namespace. This would allow us to have better control over shape of exposed apis without being tied to the internal module structure we use.
For example, assuming we have three module files:
module1
module2
module3We then define a re-exports module like this:
import * as module1 from './module1'; import * as module2 from './module2'; import * as module3 from './module3'; export const lib = { ...module1, ...module2, ...module3};We then use the
libnamespace to access all members of module1...3. But the members of these internal modules are also exposed on the global 'namespace' which pollutes the api surface. This cannot be avoided due to the way the module system works, but if we were able to exclude these files from intellisense auto-import it would make them practically hidden and thus partially solve our problem.I also would love to see this feature.
I recently created a library named rocon and it hasreact.d.tsat the root directory so that users can import stuff from"rocon/react". Thereact.d.tsreexports everything from./lib/react.The problem is that TypeScript's auto-import suggestion prioritizes importing from
rocon/lib/reactrather thanrocon/react. So it would be nice to exclude files insliderocon/libfrom the suggestion.Reacted by EthanRyan Cavanaugh (@RyanCavanaugh) It looks like this ticket generated quite a bit of feedback since you added that label. Is there any other specific feedback you're looking for?
I liked the prior comment's example of a real-life file layout that caused problems.
I have a different use-case for asking for the same (or perhaps a different, but very similar) feature.
I have a codebase which uses a couple of libraries which have thousands of types defined in them (e.g. the "aws-sdk" library has, by my count, 28MB of ".d.ts" files). These libraries are only used in a couple of places in this codebase. It appears that their entire contents get considered for auto-suggestion everywhere. I believe this makes IDEs misbehave (I see VS Code spends >500ms in
JSON.parse(), I'm told that IntelliJ exhibits weird behaviour) when typescript sends the IDE a big auto-complete candidate list.Since I only use those libraries directly in a handful of files, it would be very useful to be able to omit them from typescript's auto suggestions. It would be even more useful to be able to turn auto suggest for them back on in just the specific files where I do want to use them.
As a workaround, I'm considering splitting my project into multiple packages (in one repo) so that the main top-level package doesn't have a direct dependency on the big libraries & their types aren't visible in it.
Reacted by Georgii Dolzhykov, Yuriy, Guillem, DG Christensen, Huw McNamara and SebastianI have a different use-case for asking for the same (or perhaps a different, but very similar) feature.
...snipIssue #32174 looks like it's describing the same performance problem that I'm having & I'm looking for a way to work around. (FWIW I personally don't view it as a bug: expecting an analysis tool to be fast when feeding it 28MB of .d.ts files seems unreasonable to me, so I'd be ecstatic with a workaround for it rather than a "fix".)
Disabling autoimports with "typescript.suggest.autoImports" does fine for me, as the
Quick fixfunctionality does the auto importing well enough, even though it would be nice to be able to exclude some folder paths to improve perfomance.Reacted by Richard Barrell and karikeraReacted by Richard Barrell and Tomáš SzaboI have a Vue application with a
main.ts:import Vue from 'vue' import './plugins/logger' import './plugins/axios' import App from './App.vue' import router from './router' import store from './store' import i18n from './i18n' // Auth needs axios and vuex (in store) defined import './plugins/auth' import vuetify from './plugins/vuetify' // Make sure to register before importing any components import './class-component-hooks' import './plugins/caches' Vue.config.productionTip = false new Vue({ router, store, vuetify, i18n, render: h => h(App) }).$mount('#app')
I am using a code action on save to organize imports automatically. On this very file, I have:
import Vue from 'vue' import App from './App.vue' // Make sure to register before importing any components import './class-component-hooks' import i18n from './i18n' // Auth needs axios and vuex (in store) defined import './plugins/auth' import './plugins/axios' import './plugins/caches' import './plugins/logger' import vuetify from './plugins/vuetify' import router from './router' import store from './store' Vue.config.productionTip = false new Vue({ router, store, vuetify, i18n, render: h => h(App) }).$mount('#app')
As you can see, the import order is now wrong, since
authis imported beforeaxios.Organize Imports is a very good features, especially on save, but I need to exclude this specific file from it. Even an inline comment could do the trick.
This would be really useful for Vue as some libraries use an intermediate package in order to support Vue 2 and Vue 3 at the same time. The package is named
vue-demiand is used by the libraries, but never in the application. So when people are using libraries usingvue-demi(which points to either Vue 3 or Vue 2 depending on the installed dependencies), the auto-import features automatically addsimport { ref } from 'vue-demi'instead of the correspondingimport { ref } from 'vue'orimport { ref } from '@vue/composition-api'. This is very easy to overlook and can cause very subtle and hard to debug issues.Given the existing options of
typescript.preferences.import...and some others, maybe there could be an optiontypescript.preferences.excludeAutoImports: string[]that exclude paths and package names. Maybe even a glob if that even makes sense but I think ignoring a whole folder would be enough.Reacted by Adrià Fontcuberta, Ryan Cavanaugh, Ferenc Tamás, aki77, ねこマン, jamie-pate, Aaron Sherwood, Aideen NasiriShargh, Michael W Clark, Vinícius Feitosa da Silva and 1 moreMaybe the
exportskeyword frompackages.jsonis not a propper standard yet despite being widely supported, but it could be used as guideline of the preferred import path.Whenever I want to import
{Logger}from my@app/core/logspackage within{repo}/packages/coreI am suggested imports from- '../../core/src/logs'
- '../../core/build/logs'
- '../../core/dist/logs'
- '../node_modules/@app/core/logs'
Would it be so strange looking into
/packages/core/package.jsonand guess I just want this?- `@app/core/logs'
Currently it is not even suggested. I would even argue that any relative import that pass by a folder with a
package.jsonfile should be removed from the list of suggestions.@chakra-ui/reactis facing the same issue, it's reexporting everything, but autocomplete prefers direct imports from@chakra-ui/buttonetc.Reacted by with-heart, Ethan and Cody Richmond44 remaining items
The current implementation doesn't cover nodejs built-in modules, right?
It does. You just have to specify filenames or globs that cover the file(s) where those ambient modules are declared (whatever shows up in Go To Definition on the module specifier).
Every time someone proposes a very reasonable sounding change to auto-import heuristics, we find that implementing it makes the experience worse for ~50% of people. When “local” modules are given priority, people in really large codebases get mad that
Componentgets auto-imported from"../../../../../apps/email-templating/external/__mocks/types/flux-capacitor"when they obviously meant to import from"react". It can definitely be worth revisiting these things from time to time, but my preference is to come up with solutions that don’t make zero-sum trades in sorting/priority.Reacted by Thijs Koerselman and JacobAndrew Branch (@andrewbranch) Awesome. For me, adding
@types/node/assert.d.tsand@types/node/console.d.tsfixed my problem 👍Reacted by Adam... but somehow it doesn't work for "log" coming from the debug module. Vscode points to
"@types/node/debug/index.d.ts"but including it in the list of exclude patterns has no effect for me.Reacted by Vinícius Feitosa da SilvaReacted by Andrew BranchThat file doesn’t exist in @types/node, so I’m not sure what you’re seeing.
Andrew Branch (@andrewbranch) I got confused. It pointed to @types/debug, an external dependency. Everything seems to work fine after all 🎉
Reacted by Andrew Branch- Update your
settings.jsonfile:
"javascript.preferences.autoImportFileExcludePatterns": ["**/node_modules/@types/node/**"], "typescript.preferences.autoImportFileExcludePatterns": ["**/node_modules/@types/node/**"],
- Then reload your VSCode
Reacted by Yuriy, Vinícios Barbosa, Lilian Saget-Lethias, Lucas Caton and Christopher Carman- Update your
I wanna exclude all the import suggestions from "data-fns".
{ "typescript.preferences.autoImportFileExcludePatterns": [ "date-fns", "**/date-fns", "**/date-fns/**", "**/date-fns/**/*", "node_modules/date-fns", "**/node_modules/date-fns", "**/node_modules/date-fns/**", "**/node_modules/date-fns/**/*" ], "javascript.preferences.autoImportFileExcludePatterns": [ "date-fns", "**/date-fns", "**/date-fns/**", "**/date-fns/**/*", "node_modules/date-fns", "**/node_modules/date-fns", "**/node_modules/date-fns/**", "**/node_modules/date-fns/**/*" ] }I have tried these but still not working.
Typescript version: 5.3.2
VSCode version: 1.85.1
OS: WindowsReacted by Nazmus SayadCurrently only workspace-relative paths (starting with
./or../) work on Windows. A fix is in progress.Reacted by Nazmus SayadGot it....
After using:
./**/node_modules/date-fnsIt's working
Reacted by Andrew Branch, Nazmus Sayad, GabenGar and Luca SchultzAndrew Branch (@andrewbranch) This is great work. Very helpful. I can't figure out excluding built-ins though ?
typing
logi getimport {log} from "console"andconsole.log($0)snippet is next option, where import jest gets in the way
also typingbeforeEachi getimport {beforeEach} from "node:test"when I have vitest or jest already in importsnon of these work:
"typescript.preferences.autoImportFileExcludePatterns": [ "console", "node:test", "**/node_modules/@types/node/**", "./**/node_modules/console" ],testing on Windows 10
VSCode 1.85.2
"typescript": "^5.2.2"Reacted by Michal Srb./**/node_modules/@types/nodeshould do it. Also, leading with./shouldn’t be necessary by now if you’re using TypeScript nightly or VS Code Insiders.I'm working on an Ionic using Angular's standalone components and they give you the following settings on a newly generated project:
"typescript.preferences.autoImportFileExcludePatterns": ["@ionic/angular/common", "@ionic/angular"]
But it doesn't seem like it does what is intended, because firstly, the first entry
@ionic/angular/commonis completely useless, since every single import under@ionic/angularis excluded, including the imports from@ionic/angular/standalonewhich you'd expect to be allowed, since it's where all the imports you need from their package reside.I also found the option
typescript.preferences.autoImportSpecifierExcludeRegexes, which as per it's description:Specify regular expressions to exclude auto imports with matching import specifiers. Examples: ^node: lib/internal (slashes don't need to be escaped...) /lib\/internal/i (...unless including surrounding slashes for i or u flags) ^lodash$ (only allow subpath imports from lodash)should allow me to exclude the other imports while maintaining
@ionic/angular/standalonethat I need, but it does not seem to work, at all.Reacted by Raphaël Balet and Stefan MireaCan you open a new issue following the template with repro steps?
Can you open a new issue following the template with repro steps?
As soon as I said that here I saw that there was a new VS Code update, turns out that fixed the issue immediately for
typescript.preferences.autoImportSpecifierExcludeRegexes. I was gonna say that here but I couldn't find where I had posted anymore 😅Reacted by Andrew Branch and kirilsvReacted by kirilsv and Stefan MireaReacted by NorLzI also have a suggestion entry I like to be gone forever. Is there way to remove it ?
Reacted by Jason Kuhrt, Arthur and Vladislav Tsepilov
Search Terms
autoimport, exclude, ignore, isolation, encapsulation
Suggestion
We need a way to exclude files from auto import. Not from the project, only from the auto import suggestions.
Use Cases
My project includes a .d.ts file (generated from the previous version of the project) with legacy data structures (interfaces), many of which have the same names as their counterparts, newer data structures. As that file uses
declare module "..." { ... }syntax, imports from it are non-relative, which is why auto import gives them a higher priority whereas modules with the newer structures have relative paths. The result is that the 'Add all missing imports' command constantly creates lots of wrong imports. If only there were a way to suppress suggestions for that specific module. I want to import from it only in rare cases.I feel like this problem kind of defeats one of the important points of modules: I wanted to isolate those legacy definitions inside their module and forget about them, but because of this auto import issue they constantly get in the way.
Another example. Type definitions for libraries are in no hurry to use the new
assertsfeature of TS 3.7 for compatibility reasons. When I defined my ownassertfunction to benefit from this feature, VS Code started to insist on importingassertform Node'sconsolemodule instead, so, for lack of a better solution, I ended up renaming the function.Checklist
My suggestion meets these guidelines: