Feature Request: Linter Rule for Explicit Imports Using `show` or `as`

[frank-weindel]

Similar to JavaScript/TypeScript ES Module syntax, create a linter rule that forces developers to explicitly show every imported symbol (e.g., classes, functions, constants, extensions) from a library or use the as keyword to explicitly import an entire library under a namespace alias symbol. This rule could be used by teams that would like to opt-in to have it be clear from the top of every file what library each symbol comes from. While static analysis and hovering over a symbol in an IDE can help you find what library something comes from, it is not possible to tell from a Pull Request/file view in GitHub or by simply looking at a raw file. Such a lint rule would make the code more readable when IDE tooling is not available. This lint rule should also be automatically fixable using tooling that exists today.

I'm curious what thoughts the Dart community has for such a rule. I'm a relatively new Dart developer so I'm sure I'm missing some important implications for such a rule and the encouraged use of it.

Justification

1. Improved readability: By explicitly listing all imported symbols or using a namespace alias, it becomes immediately clear what is being used from each library without needing to rely on IDE tooling.
2. Better code reviews: In code reviews (e.g., on GitHub), reviewers can easily see where each symbol originates without needing to cross-reference the IDE or search for definitions.
3. Reduced namespace pollution: Explicit imports or namespace aliases prevent accidental usage of unintended symbols from a library, reducing the risk of conflicts or unintended dependencies.
4. Consistency: Enforcing explicit imports or namespace aliases ensures a consistent style across the codebase, making it easier for teams to maintain and understand the code.
5. Precedent in other languages: Languages like JavaScript/TypeScript and Python encourage or enforce explicit imports or namespace aliases.
6. Existing Tooling support: This rule could be automatically fixable using existing tooling to reduce the burden of adoption.
   • At least with the VSCode Dart plugin, imports can automatically be resolved using the show keyword.
   • 
   • 

Examples

Allowed

// Explicitly importing specific symbols using `show`
import 'package:example/example.dart' show MyClass, MyFunction;

// Using a namespace alias with `as`
import 'package:example/example.dart' as example;

void main() {
  // Using explicitly imported symbols
  MyClass myClass = MyClass();
  MyFunction();

  // Using symbols via the namespace alias
  example.AnotherClass anotherClass = example.AnotherClass();
}

Disallowed

// Importing the entire library without `show` or `as`
import 'package:example/example.dart';
// Importing a library with the `hide` keyword
import 'package:example/example2.dart' hide MyHiddenClass;

void main() {
  // This usage is disallowed because it's unclear where the symbols come from
  MyClass myClass = MyClass();
  AnotherClass anotherClass = AnotherClass();
}

Further Thoughts

Performance Impact

This rule should have minimal performance impact during linting, as it primarily analyzes import statements and their usage within a file.

Configuration Options

The rule could include configuration options such as:

• Allowing implicit imports for specific libraries.
  • Intended for well-used core libraries (e.g., dart:core, package:flutter/material.dart)
  • Using hide would be allowed for these libraries.
• Enabling/disabling the allowance of as namespace aliases.
  • Some teams may opt to avoid as for stylistic reasons.

Naming

Rule name ideas:

• explicit_imports
• explicit_symbol_imports
• no_implicit_imports
• require_explicit_imports

[FMorschel]

FYI @Wdestroier JIC you know some people that would like this idea.

[FMorschel]

As a note, @frank-weindel;

• Feature request (analysis server): Import multiple symbols in show clause(s) at once #56608

The issue above should have various related links of issues/fixes that make this request easier to follow today (just pointing because there are still some fixes/enhancements that will only be available on Dart 3.8 - you can see that by opening the mentioned cobybara commit and looking at the tags).

[bwilkerson]

I'm also interested to know what the community thinks of such a rule.

I'm guessing, though, that we aren't likely to include this in any of the standard rule sets (core, recommended, or flutter), and that might prevent us from implementing it.

1. Improved readability

I don't know whether you use parts in your code, but this doesn't negate the need to traverse to the defining compilation unit to see what's being imported, though it would still help once you've navigated there.

I'll just note that the enhanced parts feature will also have some impact on readability by allowing different parts in a library extend the imports from the parent compilation unit. It isn't clear yet what kind of support users will need if this feature becomes more widely used (outside of code generators), but we should consider the implications of the feature when designing the lint.

[Wdestroier]

Good idea! I would keep this lint enabled, because currently I need to keep an eye in the import section to check if I didn't import anything without the show clause by accident. Can the lint have an option to ignore files? For example:

ignore:
  - 'package:flutter/material.dart'

[FMorschel]

@Wdestroier, currently, no lints accept configurations, here is the issue requesting this #57673.

[frank-weindel]

Good idea! I would keep this lint enabled, because currently I need to keep an eye in the import section to check if I didn't import anything without the show clause by accident.

I have a section in my request covering that case.

[frank-weindel]

I'm guessing, though, that we aren't likely to include this in any of the standard rule sets (core, recommended, or flutter), and that might prevent us from implementing it.

Are there any set criteria for new rules to be added that don't fall into one of those three categories?

[bwilkerson]

Not at this point, no. We've been needing for a while to create a set of criteria for what we think we should be supporting and what we think should depend on the community to support, but so far we haven't done so.