Skip to content
Many Lints

prefer_module_barrel_imports

v1.2.0WarningConfigurableArchitecture

Reports imports into another module that bypass its barrel. Direct imports inside the same module remain allowed. This rule is in no preset; enable it by name. By default a module is a directory directly below lib, with an entry point named after that directory, such as lib/users/users.dart.

Don’t

Section titled “Don’t”

In lib/orders/page.dart, given lib/users/model.dart declaring User:

import '../users/model.dart';


User? selectedUser;

Do

Section titled “Do”

Export model.dart from lib/users/users.dart, then import that barrel:

import '../users/users.dart';


User? selectedUser;

Both relative and package imports are checked, including every conditional-import branch. Generated source files are skipped. Imports into unconfigured external packages are unaffected. Missing import targets remain the analyzer’s concern.

There is no quick fix: a barrel might not export the required names, or might introduce an ambiguous name. Review its exports before changing an import.

Options

Section titled “Options”
analysis_options.yaml
many_lints:
  rules:
    prefer_module_barrel_imports:
      module_roots: [lib]
      package_entry_points: [package:models/models.dart]
Option Type Default Description
module_roots List of strings [lib] Package-relative parent directories of modules. The longest matching root wins.
package_entry_points List of strings [] Package URIs required for external consumers and same-package files outside lib. Inside lib, importing that package’s own umbrella is reported to prevent an import back into the umbrella.

Use include and exclude to scope approved exceptions. An empty or wrongly typed module_roots uses [lib]. An entry point is a convention, not a proof of layer separation: a barrel can still export infrastructure to presentation.

Turning this rule off

Section titled “Turning this rule off”
many_lints:
  rules:
    prefer_module_barrel_imports: false
Section titled “Related rules”