exportFromImports
Reports imports that are re-exported and could use export...from syntax instead.
✅ This rule is included in the tsstylisticandstylisticStrictpresets.
When re-exporting from a module without otherwise using the imported value, it’s unnecessary to import and then export.
It can be done in a single export...from declaration, which is more concise and makes the re-export intent clearer.
Examples
Section titled “Examples”Re-exporting Default Export
Section titled “Re-exporting Default Export”import defaultExport from "./foo.js";export default defaultExport;export { default } from "./foo.js";Re-exporting Named Export
Section titled “Re-exporting Named Export”import { named } from "./foo.js";export { named };export { named } from "./foo.js";Re-exporting Namespace
Section titled “Re-exporting Namespace”import * as namespace from "./foo.js";export { namespace };export * as namespace from "./foo.js";Multiple Re-exports
Section titled “Multiple Re-exports”import defaultExport, { named } from "./foo.js";export default defaultExport;export { defaultExport as renamedDefault, named, named as renamedNamed };export { default, default as renamedDefault, named, named as renamedNamed,} from "./foo.js";Options
Section titled “Options”This rule is not configurable.
When Not To Use It
Section titled “When Not To Use It”If you prefer the explicit import/export pattern for clarity in your codebase, this rule may not be for you.
Further Reading
Section titled “Further Reading”Equivalents in Other Linters
Section titled “Equivalents in Other Linters”- Biome:
noExportedImports - ESLint:
unicorn/prefer-export-from
Made with ❤️🔥 in Boston by
Josh Goldberg and contributors.