Usefulness of distinct 'single' and 'multiple' styles for sort-imports

What rule do you want to change?

sort-imports

The issue

Currently, the ‘single’ style from the ‘memberSyntaxSortOrder’ option, covers both of these lines:

import a from 'a';
import {b} from 'b';

This means that this:

import {a} from 'a';
import {b, c} from 'b';

Would be incorrect, as the first line is considered ‘single’, while the second line is considered ‘multiple’, yet clearly they’re the same import style and all that differs is the number of imported members. I don’t see much value in this. I expected that ‘single’ imports would mean ‘default imports’, i.e. the first line in the first example, but not the second line, which I would consider ‘multiple’ (even though it is only importing one member) as it is a different style. However, it is also possible to import the default export and other members within the same line, e.g.

import React, {useEffect, useState} from 'react';

Perhaps this is the reasoning for the distinction between single and multiple, rather than between default and non-default. However, I don’t see the value in treating the two import lines in the first example as the same style (clearly they aren’t), and grouping on the number of imported members (which does not feel much like a ‘style’). I feel that it would be better to either remove the distinction between single and multiple, or change the groups/styles to something like ‘none’, ‘all’, withDefault’, and ‘withoutDefault’, so that you’d end up with something like this:

import 'none';
import * from 'all1';
import * from 'all2';
import a from 'a'; // has a default import
import b, {f, g} from 'b'; // has a default import
import {d} from 'd'; // does not have a default import
import {e} from 'e'; // does not have a default import

Are you willing to submit a pull request to implement this change?

Possibly.

[mdjermanovic]

A backward-compatible change then would be to treat that as an alternate set of options, as the previous issue suggests, rather than modifying the existing set?

Exactly! I think we shouldn’t even deprecate the existing set of items (["none", "all", "multiple", "single"]), but just allow the alternate set instead, so the users could choose either based on their preferences.

[eslint-deprecated[bot]]

Unfortunately, it looks like there wasn’t enough interest from the team or community to implement this change. While we wish we’d be able to accommodate everyone’s requests, we do need to prioritize. We’ve found that issues failing to reach accepted status after 21 days tend to never be accepted, and as such, we close those issues. This doesn’t mean the idea isn’t interesting or useful, just that it’s not something the team can commit to.

Thanks for contributing to ESLint and we appreciate your understanding.