Problem

Currently, there is no rule within eslint-plugin-import to disallow the usage of barrel files.

Barrel files, while convenient in certain scenarios, can introduce challenges in larger codebases, leading to maintenance issues, implicit dependencies, and potential pitfalls for developers.

Example of a barrel file:

export * from './util-a';
export * from './util-b';
export * from './util-c';

Proposal

I propose the addition of a new rule that disallow the usage of barrel files explicitly.

This rule would help teams enforce a code structure that minimizes the drawbacks associated with barrel files and promotes a more transparent and maintainable codebase.

I wasn't sure if this rule would belong in this plugin, but I think it would make sense alongside rules like no-cycle.

Why disallow barrel files?

• Performance overhead: See Marvin Hagemeister’s blog post on this topic where he measures the overhead cost of loading 50,000 modules in Node.js.

• Implicit dependencies: Barrel files may introduce implicit dependencies, making it harder to track dependencies and understand the code's structure. A rule against barrel files would promote explicit imports, aiding in clearer dependency management.

• Circular dependencies: Barrel files can increase the likelihood of circular dependencies. The new rule would help prevent such dependencies, reducing potential issues during development.

• Tooling compatibility: Some tools and bundlers may not handle barrel files optimally, hindering features like tree shaking and chunking. The rule would ensure better compatibility with various development tools.

Maintenance

• Transparency: Avoiding barrel files can enhance code transparency by making it clearer where specific functionalities are defined. This improves the overall readability of the codebase.

• Development overhead: Barrel files can become challenging to maintain as the project scales. The proposed rule would encourage developers to avoid relying on a central file for exporting modules, reducing the risk of overlooked updates.

• Unused imports: Barrel files might lead to unused imports, impacting the size of the bundled code. The proposed rule would encourage developers to import only what is needed, reducing unnecessary code bloat.

Implementation

• It's possible to detect barrel files instantaneously using es-module-lexer via Facade detection.

• Auto fix may be possible with a disclaimer that if their barrel files are not compliant with having zero side-effects, it can introduce breakage. I think eslint-plugin-import in particular is well positioned to implement an auto-fix as it includes resolution logic.