Adopt ESLint core `sort-imports` rule into `import/order`

[JounQin]

The core eslint rule will support most TS usecases, but it won't support "import equals" and it won't allow different treatment of type/value imports.

That being said - there are so many different sorting rules and plugins honestly I wouldn't want to add an extension rule to ts-eslint.

There are better alternatives like import/order or simple-import-sort/imports for example.

We already made this mistake with the no-duplicate-imports rule (import/no-duplicates is a much better version, and we'll be deleting our version in the next major).

Originally posted by @bradzacher in #2520 (comment)

[JounQin]

cc @bradzacher @ljharb

Let's continue the discussion here.

[ljharb]

What features does the core rule have that we lack?

The only one I'm aware of off the top of my head is the ability to sort named imports within a single import (or possibly export) statement.

[JounQin]

I think the important first task will be to thoroughly audit the core rule, and figure out what the actual missing feature comparisons are.

For me personally, I only need a ignoreMemberSort option, and it should be false by default.

[ljharb]

I think that you mean the reverse? a enforceMemberSort option that's false by default?

[JounQin]

I think that you mean the reverse? a enforceMemberSort option that's false by default?

That would be great, I just want to point out how ESLint core handle this in sort-imports rule.

[JounQin]

@ljharb Are we in agreement? (Is this change accepted? I'd like to work on this, if so.)

[ljharb]

I'd first like to understand what are all the feature gaps - if we're trying to replace the core rule, then we'd need to account for all of its use cases.

[JounQin]

I'd first like to understand what are all the feature gaps - if we're trying to replace the core rule, then we'd need to account for all of its use cases.

Did you mean https://eslint.org/docs/latest/rules/sort-imports#options?

[ljharb]

Yes, and in particular, the use cases provided for by the various combinations of options.

[JounQin]

Yes, and in particular, the use cases provided for by the various combinations of options.

So I'm still not for sure what's the next action to do? Maybe what options should be provided?

[ehoogeveen-medweb]

One thing I would not like to see is for import/order to adopt the behavior of sort-imports where sorting by member syntax appears to be mandatory and memberSyntaxSortOrder, if provided, must be an array containing all four values. I don't understand why enforcing a specific ordering between imports with a single named import and imports with multiple named imports is desirable, much less mandatory.

Aside from the mentioned ignoreMemberSort, I guess the other option that sort-imports has that import/order does not is ignoreDeclarationSort: import/order lets you sort by import path, but not by import name (though personally I'm not sure sorting by import name makes much sense).

Edit: Thinking about it a bit more, I suppose that

• sort-imports was designed to group by syntax (namespace, default and named (as single/multiple)) and sort by import name.
• import/order was designed to group by import type/path (builtin, external, internal, parent, sibling, ...) and optionally sort by import path.

So there really isn't a lot of overlap between the two, but sorting names inside a named import would be a nice enhancement.