import/order relative import sorting order changed in 2.27.0

[remcohaszing]

Given the following rule config:

module.exports.rules = {
  'import/order': [
    'error',
    {
      alphabetize: { order: 'asc', caseInsensitive: true },
      groups: ['builtin', 'external', 'internal', ['parent', 'sibling', 'index'], 'object'],
      'newlines-between': 'always',
      warnOnUnassignedImports: true,
    }
  ]
}

In eslint-plugin-import 2.26, sibling imports were sorted after parent imports. In versions 2.27.0 to 2.27.5, siblings are sorted before parents.

Here’s an example of previously valid, but now invalid code:

import { fooz } from '../baz.js'
import { foo } from './bar.js'

[remcohaszing]

I think this is also what @cojoclaudiu meant with #2669 (comment), but it appears to be unrelated to that issue.

[btecu]

Also having issues with the import/order getting:
error `@ember-data/model` import should occur after import of `@ember/template` import/order

[ljharb]

Indeed, this seems to be broken. cc @Pearce-Ropion

[Twipped]

Definitely should have been a breaking change, at a minimum.

[Pearce-Ropion]

Given that its a bug, I don't think a breaking change would have made sense since it wasn't intentional.

[ljharb]

@Twipped indeed, it's only a breaking change if it's intentional (and i'm not sure what would be larger than "breaking change")

[Pearce-Ropion]

Ok, I've confirmed that this is caused by the alphabetical sortingFn introduced in 347d78b. The sorter is sorting parent imports after siblings because ../ is sorted after ./ alphabetically. Currently the sorting fn has no knowledge of nested groups, it will just sort all elements that are in the same group alphabetically.

@ljharb What is the expected behavior for nested groups? The docs aren't very clear.
https://github.com/import-js/eslint-plugin-import/blob/main/docs/rules/order.md#groups-array

In the description for groups it says:

The enforced order is the same as the order of each element in a group.

But in the example given for groups it says that nested groups can be mingled together

> ['sibling', 'parent'], // Then sibling and parent types. They can be mingled together

And then there is nothing in the alphabetize description that relates to the sorting of nested groups.

---

My assumption is that we should sort nested groups in element order and then alphabetically. If this is the case, the alphabetical mutations will need to be aware of the group order which will make that code much more complicated.

Alternatively, we can change how the initial ranks are set by increasing the rank within nested groups in addition to just between groups.

Thoughts?

[ljharb]

I think that the primary thing is to avoid the regression - so the default behavior should remain "whatever it did before".

However, if the ideal behavior we decide on is different, we should also provide an option for that behavior.

I would assume that ['sibling', 'parent'] means that neither one should have any preference. If they want siblings sorted before parents, they'd do 'sibling', 'parent' without the array.

[Pearce-Ropion]

I would assume that ['sibling', 'parent'] means that neither one should have any preference. If they want siblings sorted before parents, they'd do 'sibling', 'parent' without the array.

Unless you want sibling to be sorted before parent without newlines.

[ljharb]

I believe that's what the distinctGroup option is for?

[jraoult]

Like @Pearce-Ropion, I've been relying on the fact that nested groups respect the array order and
then set "newlines-between": "always" to get a split between them.

I believe that's what the distinctGroup option is for?

The doc seems to imply that distincGroup is for pathGroups only (cf. https://github.com/import-js/eslint-plugin-import/blob/main/docs/rules/order.md#distinctgroup-boolean). So are you saying that to get stable ordering in a nested group and newlines between groups, we should use pathGroups instead of groups?

[ljharb]

ah, fair point. We don't seem to have a way to avoid newlines between groups.

or, rather - the only way we currently have to signal "treat these two groups differently" is putting them in an array. One thing that could imply is "don't newline between them, but keep their relative ordering", and another thing that could imply is "treat all groups in the array as being of equal rank".

It can't imply both, so which one should it imply?

The enforced order is the same as the order of each element in a group

This in the docs implies to me that it should be the former. If that's what previous versions of the plugin in v2 do, then I think that's what we should go with - and if someone wants the intermingling, then we'd need a new feature request filed for that, after this bugfix is done.