← Back to rules

unicorn/prefer-export-from Style

💡 A suggestion is available for this rule.

What it does

When re-exporting from a module, it's unnecessary to import and then export. It can be done in a single export…from declaration. This rule encourages using direct re-export syntax (export ... from) instead of importing and then exporting. It helps reduce boilerplate code and keeps the module scope clean by avoiding unnecessary local bindings.

Why is this bad?

Separating re-exports into import and export statements is discouraged because it unnecessarily pollutes the current module's scope and adds redundant boilerplate code.

Examples

Examples of incorrect code for this rule:

import defaultExport from "./foo.js";
export default defaultExport;

Examples of correct code for this rule:

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

Examples of incorrect code for this rule:

import { named } from "./foo.js";
export { named };

Examples of correct code for this rule:

export { named } from "./foo.js";

Configuration

This rule accepts a configuration object with the following properties:

checkUsedVariables

type: boolean

default: true

When false, if any import binding is used somewhere other than a re-export, all variables in the import declaration are ignored.

How to use

To enable this rule using the config file or in the CLI, you can use:

Config (.oxlintrc.json)

{
  "rules": {
    "unicorn/prefer-export-from": "error"
  }
}

Config (oxlint.config.ts)

import { defineConfig } from "oxlint";

export default defineConfig({
  rules: {
    "unicorn/prefer-export-from": "error",
  },
});

CLI

oxlint --deny unicorn/prefer-export-from

Version

This rule was added in vnext.

References

• Rule Source
• Upstream rule docs
• Open rule in Oxc Playground