Rule Proposal: export-style

[k15a]

Hey,

while working on #632 / #620 I was thinking about a new rule.

The rule would lint the style of the export statements. There are 2 styles which I think would be good options.

// "exports-style": ["error", "oneline"]
// Lints that all export statements are only one line

// valid

export default 'string'

export const bool = true

export { foo }

export connect(mapStateToProps, mapDistpatchToProps)(Component)

// invalid

export default function log(...args) {
    console.log(...args)
}

export function add(x, y) {
    return x + y
}

// not sure if this should be invalid or an exception

export {
    foo,
    bar,
    baz
}

and

// "exports-style": ["error", "variables"]
// Lints that you only export variables

// valid

export default foo

export { bar }

export {
    baz,
    qux
}

// invalid

export default 'string'

export const bool = true

export connect(mapStateToProps, mapDispatchToProps)(Component)

export default function log(...args) {
    console.log(...args)
}

export function add(x, y) {
    return x + y
}

I think that would be a great addition to #632 / #620.

What are you thoughts about this rule?

[ljharb]

Does #712 cover this?

[k15a]

#712 Covers the second style but not the first I think.

[ljharb]

Could you explain the value in enforcing either style? (I’m not a fan of #712’s rule personally)

[k15a]

So I've seen some people prefering all export statements at the end of the file and only exporting the variables / functions which are defined previously. This style is covered by #712 and #632. The advantage of this style is that when you open a file you know that you can see everything that's exported by the file at the end of the file.

Personally I prefer to have the export statements in front of the variable / function declaration because then I can quickly see that a function is also needed outside of the file and I have to care about the integration outside of the file as well.

Hopefully this explains the value of either style.

[ljharb]

So, to clarify: you want a rule that will enforce that everything exported is initialized as part of the export statement? If so, that would prevent re-exporting anything that was imported, would it not?

[k15a]

So we have the current convention in our code:

// if you can export something directly export it directly
export const foo = 'hello'
export function bar() {}
export default function baz() {}

// if you can't export it directly have the export statement directly after the declaration
const foo = 'hello'
export default foo

So this rule should be only enforced when it's possible to write everthing together.
I am not sure if this rule is worth the effort so I am also happy if it's out of the scope of eslint-plugin-import.

[ljharb]

I'm not convinced yet either way, but I am definitely leaning towards it not being something that makes sense for this plugin.