🗣️ Standardize order of the imports in a file

[abhinavdalal]

relates to #20

The goal is to order the imports based on type of import; philosophy in general is that code closer to the file is imported after code further away. this may need some config around it however.

proposed order for front end js files:

• library imports
• api function imports
• component imports
• css imports
• relative path imports

sort it alphabetically within these categories

we may need some intelligent config that handles server side js files

my thought is a team should be able to quickly (with 5 min) configure rome (preferable via answering a few questions) and then when they run fix the tool that will order all the imports as per config.

we surely have our strongly opinionated config set by default ;)

i am happy to contribute..

[mattcompiles]

I agree supporting import sorting would be nice. However, not sure about your order rules. They seem quite app specific. I think a more generic rule set around distance from the current file to the import would make more sense.

Prior art for reference eslint-plugin-import

[sebmck]

The biggest problem with import ordering is that it's highly specific and can effect overall module execution order that can introduce module cycles and break code, making this a pretty unsafe transform.

[abhinavdalal]

@sebmck my current understanding is that it can only break if the imports are unnamed; if that understanding is correct.. what if we enforce that no unnamed imports and then apply a set of grouping rules as discussed?

// FAILS
require('babel-register');


// PASSES
const babelRegister =  require('babel-register');

// a lot of other imports

babelRegister();

if we feel that this is a hard-to-solve problem that provides not enough value; i get it.. we can de-prioritize in the backlog if you want; but i feel we should address this well. i feel a clean import statements builds the momentum to read the file further.

again; happy to contribute for this if discussion on solution is more conclusive

[sebmck]

@abhinavdalal Module execution order is determined by the dependency order in the source code. If you have:

import 'foo';
import 'bar';

Then the order will always be foo, bar. This then works recursively for all dependencies, with the first reference being the place in which the module is executed. There are definitely places in the Rome codebase where this rule would likely break module cycles.

[gustavopch]

@sebmck What about a // rome-disable-line or something like that? Because in 99% of the cases, enforcing import order wouldn't cause troubles.

[sebmck]

That could work. We do already support rome-disable suppression comments after all. Ultimately I'm conflicted on import ordering because in an ideal world an editor would automatically fold imports as most files have so many that they're just noise, and combined with auto-imports in something like VSCode it's extremely easy to add imports as you type.

[gustavopch]

@sebmck I agree to some extent. Not sure whether Rome should assume editors are folding their imports. Even in that case, keeping them unorganized is like sweeping dirt under the carpet. You'll still have to handle the imports in some cases, like when working with git diff or git add -p.

[sebmck]

Yeah for sure, we definitely shouldn't be planning around editor dreams. Rome has capabilities already to detect module cycles which we could pair with an import order rule to make this really safe.

[ljharb]

Careful when ordering imports; it’s generally not safe to move anything across a bindingless import, as that means it has side effects where order might matter.

[lcswillems]

@sebmck Something like this Prettier plugin would be really great: https://github.com/trivago/prettier-plugin-sort-imports

[MichaReiser]

The implementation of import sorting is tracked in #3462

[arendjr]

I've created a PR that also groups different module sources: #4725

Feedback is welcome :)