Avoid barrel re-exports in auto-imports

[TheColorRed]

Bug Report

🔎 Search Terms

• autoImportFileExcludePatterns

Bug

When using the setting typescript.preferences.autoImportFileExcludePatterns, it works, however, in a mono-repo I cannot import from another package's root without using the full path to the file when excluding index.ts files.

{
  "typescript.preferences.autoImportFileExcludePatterns": [
    "./packages/*/src/index.ts"
  ],
}

I have a workspace package.json that looks like this:

{
  "name": "workspaces",
  "version": "1.0.0",
  "workspaces": [
    "packages/core",
    "packages/a"
  ]
}

In the package.json of packages/core I have this:

{
  "name": "@org/core",
  "main": "./src/index"
}

Then in the packages/a, I try to import a file from packages/core, but autoimport imports something like this even though it is exported through the main file:

import { MyClass } from '@org/core/src/classes/my-class';

The package.json for packages/a

{
  "name": "@org/a",
  "main": "./src/index"
}

The tsconfig.json for both:

{
  "extends": "../tsconfig.base.json",
  "files": [
    "./src/index.ts"
  ]
}

Expected Result

This might be a feature request, but I think it would be great if barrel files could be ignored in the auto-import if within the same module/package, as this can often lead to circular dependencies that are hard to track down.

[RyanCavanaugh]

Can you set up a sample repo, and also clarify the "expected result" ? Are you expecting a different import path to be generated, or not to be shown that import suggestion at all?

[TheColorRed]

@RyanCavanaugh I have created the repo: https://github.com/TheColorRed/vscode-autoImportFileExcludePatterns

Steps:

1. Clone the repo
2. npm i
3. In packages/helper/src/index.ts type readF and select the one that is in @org/core from the Intellisense popup.

You will then notice the auto import imports the full path to the file:

import { readFile } from '@org/core/src/files';
readFile

Now if you turn off the setting typescript.preferences.autoImportFileExcludePatterns in .vscode/settings.json and use Intellisense, the import works the way I intended:

import { readFile } from '@org/core';
readFile

Having this setting works the way I want when referencing a file in the current mono-repo project (aka when @org/core or @org/helper uses one of its own files). But when @org/helper uses a file from @org/core the wrong import is used.

Here is what I am looking for:

@org/core     -> import { readFile } from './files';
@org/helper   -> import { readFile } from '@org/core';

Here is what is happening:

@org/core     -> import { readFile } from './files';
@org/helper   -> import { readFile } from '@org/core/src/files';

[ssalbdivad]

I ran into a similar issue with this. It would be great if there were a way to exclude "index.ts" from being suggested directly while still allowing other specifiers that resolve to a file called "index.ts".

[ssalbdivad]

@andrewbranch Any chance this could fit in with some of the ongoing auto-import improvements?

Would make a huge difference to me as currently I either get imports from my main.ts entrypoints within a single package, causing circularities, or cannot get auto imports from other packages in the monorepo.

[andrewbranch]

This is super working-as-intended, and the desired behavior I think clearly doesn’t map onto autoImportFileExcludePatterns, unless you had a multi-root workspace and had different VS Code settings for each TS project, which would let you exclude your own index.ts files in each workspace root without excluding any other package’s index.ts files.

Auto-imports has a preference toward barrel files because they usually indicate the most public export of something and result in the shortest path. I would like to move away from this preference since barrel files often make build tools work poorly, but there needs to be a stronger proposal for how to make this shift, and it needs to be motivated by objective reasons, not code style aesthetics.

In the example project here, if you don’t want to import from '@org/core/src/files', then that package should declare an "exports" that prevents such a path from being resolvable. After that, if we had a setting for “avoid barrel re-exports,” it would do the job, because in the local project, you might have many ways to access some export, including a barrel file, but there would only be one way to access everything from '@org/core'.

[andrewbranch]

I feel instinctively opposed to a setting like “avoid barrel re-exports in my own files but not from my dependencies.” There are many reasons barrels are bad; the circularity problem is just one. If auto-imports is making a circularity that could have been detected, or at least looks suspicious, we should try to fix that universally, not behind a setting. I did some work like that in #47516. But given all the other barrel problems, it begs two questions:

1. Why would you want to import from barrels in node_modules? Your bundler and other tools are probably going to work better and faster if you use the deepest / most specific imports the package allows.
2. Why write them in your own code?

To me, this makes it feel like we kind of don’t need any additional settings. If you want short import paths from node_modules but you don’t want to import from your own barrels, maybe you should stop writing barrels in your code. On the other hand, if we changed settings for everyone to avoid barrels everywhere, and people started complaining about getting unwieldy auto-import paths for their dependencies, then maybe those dependencies should define "exports" that declare what subpaths are allowed.

[ssalbdivad]

@andrewbranch Maybe I should have described my use case more clearly but I don't use barrel files (or at least in the sense I normally hear them described). I only have a single main.ts file for each package which constitutes its public API- there are no nested barrel files I ever want to use internally. Is there an alternative to this for a package that wants to publish a top-level API?

I have a paths config like this that allows me to avoid having to build to see my runtime or type changes reflected e.g. in tests:

		"paths": {
			"arktype": ["./ark/type/main.ts"],
			"@arktype/util": ["./ark/util/main.ts"],
			"@arktype/fs": ["./ark/fs/main.ts"],
			"@arktype/schema": ["./ark/schema/main.ts"],
			"@arktype/attest": ["./ark/attest/main.ts"]
		}

If you have another suggestion as to how to achieve this that doesn't result in the problematic suggestions but does allow importing from a path like @arktype/schema that resolves to the entrypoint of another package in the monorepo, I'd definitely be open to it!

[ssalbdivad]

@andrewbranch Rereading your second comment, I understand more what you're suggesting now, but top-level discoverability for the API of a library feels valuable.

I would definitely not want to give that up just to avoid some obnoxious auto-imports that worst-case scenario I can manually fix. Granted it is grating given how often these kinds of imports occur, but I don't know if I can recall a library that doesn't provide some top-level export and I think there are good reasons for that.

[andrewbranch]

IMO you should never use paths. Use package manager workspaces and set up project references. That’s enough to not have to build to see type changes in the editor—references to project reference output files get transparently redirected to input files in the IDE so you get instant IntelliSense updates across projects. For fast test/dev runtime workflows, I add conditional "exports" on top of this:

{
  "exports": {
    "ts": "./src/main.ts",
    "default": "./dist/main.js"
  }
}

then set your test runner / whatever to use the ts condition.

paths goes through some pretty different auto-import code paths so I’m not sure how it might be affecting your experience.

[ssalbdivad]

@andrewbranch I actually had this kind of setup originally but it felt like a lot of extra ceremony for no extra benefit compared to using paths, at least within my own repo.

I also had the same problem with autoimports with that set up.