Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Reverse imports/group-exports #2916

Open
thgh opened this issue Nov 3, 2023 · 5 comments
Open

Reverse imports/group-exports #2916

thgh opened this issue Nov 3, 2023 · 5 comments

Comments

@thgh
Copy link

thgh commented Nov 3, 2023

Is there a way to transform each export group to export declarations?

@ljharb
Copy link
Member

ljharb commented Nov 3, 2023

Not that I know of. Why would you want that?

@thgh
Copy link
Author

thgh commented Nov 6, 2023

Because I prefer export declarations ^^ it's unfortunate that this package doesn't autofix exports

@ljharb
Copy link
Member

ljharb commented Nov 6, 2023

If it was purely about aesthetics then an option would be acceptable, but

Rationale: An export declaration or module.exports assignment can appear anywhere in the code. By requiring a single export declaration all your exports will remain at one place, making it easier to see what exports a module provides.

this is about readability and maintainability, so I think it's best not to make that easy.

@thgh
Copy link
Author

thgh commented Nov 6, 2023

It kind of is aesthetics, no?

Maintainability wise I think of these arguments:

  • Export groups add useless boilerplate as most files have only one export
  • Separating implementation and export adds mental overhead, you have to add code in multiple places -> bugs
  • Export groups add complexity in git diff -> conflicts
  • Export groups being typically located at the bottom of a file, are an after-thought, it's easy to accidentally forget one
  • Renaming an export in an export group is a two-step process, one more than needed
  • ESM export declaration syntax is very clear and concise

I must admit that having an overview of exports is a really good argument, but it only applies in a minority of files. That's why I think a rule that prefers separate export declarations also makes sense.

Do you have some pointers on how such an autofixable could be implemented?

@ljharb
Copy link
Member

ljharb commented Nov 6, 2023

Aesthetics only matters when the choices are equivalent in all other respects.

The rule currently allows a declaration when there's a single export, for the reason you indicated.

if you keep your export group sorted and use trailing commas, there'll be no diff churn.

If you are able to forget one, you're failing to write tests for it - and also failing to use the "no unused exports" rule we have.

Adding autofixing to the current rule is perfectly fine if it's safe; you could make a PR to do so.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

No branches or pull requests

2 participants