sort-exports

Please describe what the rule should do: When there is more than [x] (default: 1) exported objects in a file, rule makes sure all exported objects are combined at the bottom of the file in a single place.

What category of rule is this? (place an “X” next to just one item)

[ ] Warns about a potential error (problem) [ ] Suggests an alternate way of doing something (suggestion) [x] Enforces code style (layout) [ ] Other (please specify:)

Provide 2-3 code examples that this rule will warn about:

Bad: ES6 Export

export const MYCONST = 5;
// ...
export const myFunc = () => {};
// ...
export const myObject = {};
// ...

Good: ES6 Export

const MYCONST = 5;
// ...
const myFunc = () => {};
// ...
const myObject = {};
// ...

export {
  MYCONST,
  myFunc,
  myObject,
}

Bad: Commonjs Export

module.exports.MYCONST = 5;
// ...
module.exports.myFunc = () => {};
// ...
module.exports.myObject = {};
// ...

Good: Commonjs Export

const MYCONST = 5;
// ...
const myFunc = () => {};
// ...
const myObject = {};
// ...

module.exports = {
  MYCONST,
  myFunc,
  myObject,
}

Why should this rule be included in ESLint (instead of a plugin)? I think this rule will have a very positive impact on code readability. Because developers tend to export functions, objects, classes inline and most often, in the same file, also define unexported functions. This causes a chaotic view of the file.

As developers, like we check top of the file to see what is being imported, we should check bottom of the file to see what is being exported. This will intuitively help developers to understand what that module (file) is doing.

Are you willing to submit a pull request to implement this rule? I’d love to.

[aladdin-add]

Thanks for your interest in improving ESLint. Unfortunately, it looks like this issue didn’t get consensus from the team, so I’m closing it. We define consensus as having three 👍s from team members, as well as a team member willing to champion the proposal. This is a high bar by design – we can’t realistically accept and maintain every feature request in the long term, so we only accept feature requests which are useful enough that there is consensus among the team that they’re worth adding.

Since ESLint is pluggable and can load custom rules at runtime, the lack of consensus among the ESLint team doesn’t need to be a blocker for you using this in your project, if you’d find it useful. It just means that you would need to implement the rule yourself, rather than using a bundled rule that is packaged with ESLint.

[golopot]

This is what your are looking for: import/group-exports .