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:

• Feature Suggestion: Folder encapsulation determined by index/exports.js #2565
• Rule proposal: Disallow barrel files #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.