This rule raises an issue when code imports from a module and then immediately exports the same identifiers without using them elsewhere.

Why is this an issue?

When re-exporting from a module, using separate import and export statements creates unnecessary verbosity and intermediate variables.

The pattern of importing something just to export it again is common when creating barrel exports or module facades. However, JavaScript provides the export…​from syntax specifically for this use case.

Using import followed by export for re-exports has several drawbacks:

• It creates unnecessary intermediate variables that serve no purpose
• It makes the code more verbose and harder to read
• It requires two statements where one would suffice
• It can confuse readers about whether the imported values are used locally

The export…​from syntax is more explicit about the intent to re-export and eliminates the intermediate step entirely.

What is the potential impact?

This issue affects code readability and maintainability. While it doesn’t cause runtime problems, it makes the codebase more verbose and potentially confusing for developers who need to understand the module’s exports.

How to fix?

Replace the import and export statements with a single export…​from statement for default exports.

Non-compliant code example

import defaultExport from './foo.js';
export default defaultExport; // Noncompliant

Compliant code example

export {default} from './foo.js';

Documentation

• eslint-plugin-unicorn - Rule prefer-export-from
• MDN - export statement - Comprehensive documentation on JavaScript export statements including export…​from syntax
• MDN - import statement - Documentation on JavaScript import statements and module imports