New-rule: force re-export style

[ClementEXWiki]

Here is a proposal for a new rule: forbidding imports followed by equivalent exports, and prefer re-export syntax instead.

Example:

// Forbidden
import { obj } from 'module'
export { obj }

// Allowed
export { obj } from 'module'

I didn't find any similar rule in the docs, and I think it would be nice to have one to enforce consistent styling of re-exports.

[ljharb]

Re-exporting in general is something best avoided, especially in a barrel-file context. Rather than having a rule that enforces a consistent way to do something unadvisable, I'd rather have one that discourages re-exports entirely in favor of requiring consumers to deep-import.

[soryy708]

Related:

• https://github.com/import-js/eslint-plugin-import/issues/2565
• https://github.com/import-js/eslint-plugin-import/issues/2922

[ClementEXWiki]

I do agree that it's a bad practice ; but we have some legacy code bases where it's used all over the place, and a rule enforcing a particular writing style would be really appreciated. It could be named some like unrecommended-reexport-barrel-files or something like that to emphasize the fact that it shouldn't be used for new projects, but is still relevant for older ones.

[ljharb]

If you're going to be making changes to those files based on a rule, why not remove the barrel file instead at that time?

[ClementEXWiki]

Unfortunately this would require to rewrite thousands of imports across hundreds of files, plus update the exports fields from every package.json in every package we have (100+).

[ljharb]

Most IDEs can automate rewriting imports, but sure, a lot of tech debt means a lot of work to fix it.

[JounQin]

Same concept as https://github.com/sindresorhus/eslint-plugin-unicorn/blob/main/docs/rules/prefer-export-from.md

[seeker-3]

What's the issue with "barrel files"? Does it just make it harder to code-split and tree-shake?

Are export aliases also discouraged?

// index.js
export { default } from "./my-module.js"

I just joined a legacy codebase and we have about a million of these, but we're using the syntax

import x from "./my-module.js"
export default x

I doubt they would be convinced to get rid of index.js files, but if there was a lint rule for "prefer export from", they might be convinced to switch to the better syntax.

[ljharb]

@seeker-3 yes, that is what it does.

[seeker-3]

What if you had something like

"import/re-exports": "disallow" | "short" | "long"

"short" allows export from

export { default } from "mod"

and disallows import export

import mod from "mod"
export default mod;

"long" does the opposite

"disallow" disallows both.

The disallow option could be part of the recommended settings.