import/first and reexports

[Jessidhia]

Currently, import/first seems to require that any import comes before any export, even if the export is an export..from. Reordering them, in this case, could be a potential logic error.

Though, arguably, if the module is capable of exporting, it should also be made side-effect free...

Also related is that import/first does not allow mixing import with export {}, and separating them actually hurts readability.

Consider the following:

// `export * as comment from './comment'` but that is not standard syntax
import * as comment from './comment'
export { comment }

import * as members from './members'
export { members }

The rule will complain about the second import, but moving so all the imports are grouped would actually make it harder to tell they are being reexported.

[ljharb]

Why would that make it harder to tell?

You'd read the export { members, comment }, and then having already read the two imports, you'd know they were being re-exported.

Why is this situation any different from const foo = 3; export { foo }; const bar = 4; export { bar } (which should be const foo = 3; const bar = 4; export { foo, bar })?

[Jessidhia]

This is a small snippet of a larger file with many reexports.

Overall, I don't see any reason, anywhere, ever, for considering export {} as code. It should never trigger use before define or other similar lint warnings. If you want to consolidate your exports, then an export-specific rule should be used.

[ljharb]

Of course an export is code, as is an import - exports are conceptually like a return.

It seems like the sole purpose of the rule isn't something you want enforced; I'd suggest disabling the rule in that case.

Reordering them, in this case, could be a potential logic error.

Regrouping your import/export pairs such that imports are first, and then exports, can't possibly change the meaning of the code (assuming that the imports are all in the same order), so I'm not sure what you mean here.

[Jessidhia]

@ljharb export { foo } from 'bar'

I still want to enforce that imports are all listed before actual code, but export {} (without from) is literally defined to do absolutely nothing at runtime; there's no chance that anyone might be confused about the runtime order of export {}.

Though I guess the kind of person that would not be confused by export {} would also not be confused by import.

[Andarist]

I've also bumped into this while linking packages generated by rollup for local testing purposes (yes - I could change rule settings to ignore those directories, but that's not the point). I agree with @Jessidhia that because reexports are imports they should just be allowed there. From my POV the purpose of this rule is to avoid confusion around this:

console.log('second')
import './i-will-log-first'

Reexports on the top won't confuse people like the given snippet can.

I've created a quick PR for this https://github.com/benmosher/eslint-plugin-import/pull/1522 , merge it or close it I guess, your call - just wanted to bring up my 2 cents into this.