AbsoluteJS

absolute/prefer-inline-exports

Prefer inlining export at a declaration site over a trailing export { name } statement for local declarations.

Imports & ExportsSuggestionFixable
View on GitHub

#Rule Details

Prefers inlining export at the declaration over a trailing export { name } statement when name is a local declaration in the same file. The inline form keeps a symbol’s exported-ness next to its definition, so you never have to scroll to the bottom of a file to learn what is public.

The autofix prepends export to each fixable declaration and removes (or trims) the trailing statement. Forms with distinct semantics are left alone: re-exports with from, renamed specifiers (export { foo as bar }), type-only exports, imported bindings, declarations already exported elsewhere, and shared multi-declarator declarations. AI tooling commonly emits the trailing form when rewriting export default, and this rule cleans that up.

#Examples

Incorrect
TS
const foo = 1;
export { foo };          // → export const foo = 1;

function helper() {}
export { helper };       // → export function helper() {}
Correct
TS
export const foo = 1;
function bar() {}
export { bar as renamed };           // renamed specifier
export { helper } from './helper';   // re-export with a source

import { Sentry } from '@sentry/node';
export { Sentry };                   // re-exporting an imported binding

#Configuration

Enable this rule in your ESLint configuration:

JS
{
	rules: {
		'absolute/prefer-inline-exports': 'error'
	}
}

#When Not To Use It

If your team prefers a single "barrel" of exports at the bottom of each file as an at-a-glance public API, that convention conflicts with inlining — leave the rule off.

#Resources