[New] order: allow intragroup sorting of type-only imports via sortTypesGroup

[Xunnamius]

Resolves #2615
Resolves #2441
Resolves #2347
Resolves #2172
Related #2912

First, thanks for making eslint-plugin-import! It has saved me a lot of time and headache.

This PR implements in import/order: a new option enabling intragroup sorting of type-only imports to match intergroup sorting of normal imports.

A demo package containing this feature is temporarily available for easy testing:

npm install --save-dev eslint-plugin-import@npm:@-xun/eslint-plugin-import-experimental

Allow intragroup sorting of type-only imports

This is implemented via sortTypesAmongThemselves. The proposed documentation corresponding to this new feature can be previewed here.

Example

Given this code (which is already correctly ordered):

import type A from 'fs';
import type B from 'path';
import type C from '../foo.js';
import type D from './bar.js';
import type E from './';

import a from 'fs';
import b from 'path';
import c from '../foo.js';
import d from './bar.js';
import e from './';

And the following settings, the rule check will fail:

{
  "groups": ["type", "builtin", "parent", "sibling", "index"],
  "alphabetize": { "order": "asc" }
}

With --fix yielding:

import type C from '../foo.js'; // ???
import type A from 'fs';
import type B from 'path';
import type D from './bar.js';
import type E from './';

import a from 'fs';
import b from 'path';
import c from '../foo.js';
import d from './bar.js';
import e from './';

This is currently the technically correct behavior, but the wrong outcome in my opinion.

However, with the following settings, the rule check will succeed instead:

{
  "groups": ["type", "builtin", "parent", "sibling", "index"],
  "alphabetize": { "order": "asc" },
+ "sortTypesAmongThemselves": true
}

Of course, achieving the reverse order (type-only imports after normal imports) is possible by moving "type" to the end of groups:

{
+ "groups": ["builtin", "parent", "sibling", "index", "type"],
  "alphabetize": { "order": "asc" },
  "sortTypesAmongThemselves": true
}

It was only after implementing this feature, when I started reviewing the issues literature, that I saw #2441, which lead me to eslint-plugin-perfectionist (neat) and its implementation of "builtin-type," "external-type," etc. I much prefer this PR's implementation, which takes a similar approach to this comment. I don't see how allowing type-only builtin/external/etc imports to be sorted in a different order than non-type builtin/external/etc imports makes things less confusing. And that's before we consider custom pathGroups.

Instead, the goal of sortTypesAmongThemselves is to allow the "type" group to be sorted among itself in a backward-compatible way without the added complexity (and potential inconsistency) of adding regexp or "*-type" groups to groups. I'm already writing too much configuration. I just want to flick a switch 😅.

Additionally, the code that makes sortTypesAmongThemselves work could be extended to make something like #2912 work too (perhaps through another option), though that use case is not of interest to me currently.

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 94.81%. Comparing base (e5edf49) to head (752f00d).
Report is 2 commits behind head on main.

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #3104      +/-   ##
==========================================
- Coverage   95.08%   94.81%   -0.27%     
==========================================
  Files          83       83              
  Lines        3618     3626       +8     
  Branches     1276     1279       +3     
==========================================
- Hits         3440     3438       -2     
- Misses        178      188      +10     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[ljharb]

This is doing a lot, and is a bit of a long diff. It seems like there's 4 separate PRs to be had here:

1. NaN bugfix
2. newline controls for type-only imports
3. intragroup sorting of type-only imports
4. a new option to consolidate newlines and save space where possible.

I definitely would prefer to see 3 of those peeled off into separate PRs, so that each thing can be easily reviewed separately. Thanks!

(also, could you please add parens to ensure proper precedence is conveyed when there's a combination of && and ||?)

[Xunnamius]

I definitely would prefer to see 3 of those peeled off into separate PRs, so that each thing can be easily reviewed separately. Thanks!

Gotcha, I'll slice it up this weekend.

(also, could you please add parens to ensure proper precedence is conveyed when there's a combination of && and ||?)

I thought I ran my modifications through Prettier, but I probably missed a few blocks. I'll take a look

[ljharb]

I think prettier removes those parens, which is one of its many flaws :-)

[jftanner]

For the record, I definitely would like this feature. As evidenced by the fact that I tried to use it per the docs on main. (Edit: Because I mistakenly thought they were for the latest release.) :)

[ljharb]

@Xunnamius any progress? i'd love to get this merged for the next release.

[Xunnamius]

@ljharb Sorry, something I'm working on is, of course, taking longer than I anticipated. I hope to wrap up today or tomorrow. This PR is up next 😊

[ljharb]

This PR adds 3 options but only seems to be adding 1 to the schema. Should the schema be amended, or should 2 of the options be removed so they can land in different PRs?

[Xunnamius]

@ljharb Hmm, no this PR should still only contain the changes relevant to sortTypesGroup, but I think I see what happened with docs/rules/order.md. 752f00d is the result of rebasing this PR by hand (cherry-pick), which was required due to the rename to sortTypesGroup (the main branch has the docs PR already merged in, which was using the old name). Seems the force pushes after 752f00d tripped over what my cherry-pick was trying to avoid, but I'm not sure

EDIT: I see some complaints from codecov, I'll check 'em out

[ljharb]

If that’s the case then my bad :-)