Rule proposal: prefer-export-from

[MrHen]

There are lots of ways to export but one pattern that is unnecessary is importing something and then immediately exporting it.

Fail

import _foo from './foo';
import { bar as _bar } from './bar';

export const foo = _foo;
export const bar = _bar;

Pass

export { default as foo } from './foo';
export { bar } from './bar';

[sindresorhus]

This is a great idea. A lot of people don't know about "export from".

There are many supported ways to re-export:

export * from …;
export { name1, name2, …, nameN } from …;
export { import1 as name1, import2 as name2, …, nameN } from …;
export { default } from …;
export { default as something } from …;
export * as utils from …;

[zamboney]

I would like to make this new rule as my first issue

[MrHen]

@zamboney Go for it!

[fisker]

@zamboney Still interested to implement this rule?

[EvgenyOrekhov]

I like JSLint's stance on import/export:

JSLint recognizes a small but essential subset of the module syntax.

I don't really see benefit in this:

export { default as foo } from './foo';
export { bar } from './bar';

over this:

import foo from './foo';
import { bar } from './bar';

export {foo, bar};

I would say that it's the export ... from syntax that's unnecessary.

[sindresorhus]

@EvgenyOrekhov I disagree. But you can just disable the rule if you don't want this.

[sindresorhus]

This rule should also catch cases like:

import * as utils from './utils.js';
export {utils};

and enforce this instead:

export * as utils from './utils.js';

[fisker]

I think we should ignore this : if some specifier is used

import {foo, bar} from './foo';
bar();
export {foo}

Otherwise

import {bar} from './foo';
bar();
export {foo} from './foo';

Seems weried.

[fisker]

About autofix

import {foo} from './foo';
import {another} from './bar';

another();
// ...

export {foo};

Should we put export on top or bottom?

export {foo} from './foo';
import {another} from './bar';

another();
// ...

VS

import {another} from './bar';

another();
// ...

export {foo} from './foo';

[sindresorhus]

Seems weried.

I disagree. It only seems weird because of the articifical example. In real-world code, there would be a lot more code in a file.

The reason I disagree is that re-exporting directly improves readability and makes it clear that this one thing is just re-exported and not modified/mutated on the way. I think will also help static analysis tools to guarantee that it was just re-exported, which might alow better tree-shaking.

[sindresorhus]

Should we put export on top or bottom?

Bottom

[kirillgroshkov]

FYI, I just tried to adopt this and discovered that it breaks IntelliJ IDEA auto-import functionality (IDE does't auto-suggest imports anymore).

Example how it worked before:

// Works
import { something } from './somewhere'
export { something }

// Doesn't work:
export { something } from './somewhere'

// This doesn't work too:
export * from './somewhere'

Clarification: it does work in the same project, but does not work when this export style is used in the library and it's in your node_modules.

I know I should probably report it to Jetbrains too, but I start here. Maybe more people can confirm it and then it'll make sense to understand why it doesn't work in IDEA (and I assume WebStorm too).

[sindresorhus]

The rule just enforces valid ESM syntax. You should open an issue on IntelliJ. It just sounds like their ESM import/exports implementation is incomplete.

[kirillgroshkov]

Yes, I agree that ESM syntax is valid.

FYI, reported to Jetbrains here: https://youtrack.jetbrains.com/issue/IDEA-281957