autoImportFileExcludePatterns should have more nuance than just true/false

[axefrog]

🔍 Search Terms

autoImportFileExcludePatterns
auto import

✅ Viability Checklist

• 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 isn't a request to add a new utility type: https://github.com/microsoft/TypeScript/wiki/No-New-Utility-Types
• This feature would agree with the rest of our Design Goals: https://github.com/Microsoft/TypeScript/wiki/TypeScript-Design-Goals

⭐ Suggestion

A big point of usefulness for me regarding the typescript.preferences.autoImportFileExcludePatterns setting is that I can have a subdirectory with internal implementation details and avoid inadvertently having other parts of the application import those internal details when they contain exports with the same or a similar name to one I'm trying to auto import.

Problems:

• If I break apart my internal implementation into various internal files, the setting also prevents auto importing from working even within code inside the excluded directory. Essentially it means I miss out on the benefit of auto importing when working on the internal implementation itself.
• The externally-facing export that utilises the internal functionality and is essentially the main facade exposing that functionality -- the one that I want the rest of the project to be able to auto import -- cannot live in the same directory as its internals. This is less of an issue than the first point, but it does reduce developer freedom with respect to choices regarding file and folder organisation.

My suggestion is that the current design, which looks like this:

{
  "typescript.preferences.autoImportFileExcludePatterns": [
    "**/*.internal.ts",
    "**/*.internal/**",
    "**/internal/**",
  ],
}

Could be improved to support object entries in addition to file path strings. I'd suggest something like this:

{
  "typescript.preferences.autoImportFileExcludePatterns": [
    "node_modules/**/*",
    // Use an object to define an auto import scope
    {
      // Exclusion patterns that are part of this scope:
      "match": [
        "**/*.internal.ts",
        "**/*.internal/**",
        "**/internal/**"
      ],
      // Among exclusion patterns in this scope, the following should be filtered out of the exclusion list:
      "exceptions": [
        "**/index.ts",
        "**/*.public.ts"
      ],
      // If false, the exclusion patterns defined in this scope will not be active for files excluded from auto-import
      // because of this scope. In other words, when editing the actual files that this scope excludes from
      // being auto imported elsewhere, the excluded files themselves will still be able to auto import each other.
      "propagateExclusionScopeInternally": false
    },
    "other/patterns/**/*",
    "etc/*"
  ]
}

📃 Motivating Example

Essentially the current design of the autoImportFileExcludePatterns feature is too much of a blunt instrument. Exclusions are not just useful for dead code and things that nobody should ever want to accidentally import, but also for preventing auto imports within a project from grabbing internal implementation details from subsystems implemented within that project's codebase. A project might have many internal subsystems, each with its own folder containing internal implementation details. While working on those implementation details, you still want auto imports to work among files in that scope -- it's just that we don't want files outside that scope to be able to auto import them. autoImportFileExcludePatterns gives us a half measure in terms of the second part of that equation, but it makes working on the internal implementation details more cumbersome as we have to manually type in any import statements for files within the scope.

💻 Use Cases

1. What do you want to use this for?
   Editing. This is a developer ergonomics issue.

2. What shortcomings exist with current approaches?
   Already covered.

3. What workarounds are you using in the meantime?
   Accepting increased editing friction when using autoImportFileExcludePatterns.