Add importOrderCaseInsensitive option again

[angrybacon]

There's value in sorting uppercase first: constants, constructors and functions become sorted in that order.

Support for case sensitive sorting was dropped here #63

[IanVS]

Leaving this open so that others can vote with 👍, and we'll consider it depending on the demand.

[jar145]

I'm curious why this was removed in the first place? I'm happy to make a PR if time is the issue.

[IanVS]

It was removed because there were a ton of options previously, which goes against the philosophy of prettier. There more options there are, the more you have to think about decisions when setting it up, and the more complex the codebase becomes.

[acnebs]

I not only want case-sensitivity, but also think that this should be the default. Here is a prime example of why I think this is the case:

import {
  faAngleLeft,
  faAngleRight,
  faArrowDown,
  faArrowLeft,
  faArrowRight,
  faArrowsV,
  faArrowUp,
  faSearch,
  faSmile,
  faTvRetro,
} from '@fortawesome/pro-regular-svg-icons';

@ianvs/prettier-plugin-sort-imports sorts the faArrowsV before the faArrowsUp, which I think is very strange when you look at it. It makes much more sense for the "arrow" icon to be sorted with the other "arrow" (singular) icons, and then for the "arrows" icon to come after (or before), the point is that case-insensitivity to me seems like a very strange default.

[tony]

It was removed because there were a ton of options previously, which goes against the philosophy of prettier. There more options there are, the more you have to think about decisions when setting it up, and the more complex the codebase becomes.

Are you sure that applies in this case?

Using capitalization to indicate the type of symbol—such as STATIC, ClassOrComponent, and variableOrInstance—can lead to "disorganized" symbols:

-import { Comp, BOOL_COMP, TEXT_COMP } from './lib/constants'
+import { BOOL_COMP, Comp, TEXT_COMP } from './lib/constants'

@IanVS Are you open to bringing this option back? Seems to have a decent number of 👍's. Would this package being funded change anything? I think a lot of users appreciate your effort on the package in general!

[IanVS]

No, funding isn't the main concern here. It does seem like this has gotten some interest, so I'm open to re-adding the option. I wouldn't want to change the default, to avoid a breaking change, but I think adding in the option would be reasonable at this point. I'll be happy to review a PR if anyone would like to submit one. It should be fairly straightforward to look at the code we used to have which was removed for the last breaking release.

[alex-statsig]

One suggestion here - would it make sense to allow only applying case-sensitivity on the imported values (i.e. not the import paths)? I think its much more common to want this applied to imported values, which is what this issue originally asked about, and what @acnebs provided the example for

[acnebs]

@alex-statsig I thought about that, but the same logic applies to paths. e.g. with the example I used in the commit message.

import ExampleComponent from './ExampleComponent';
import ExamplesList from './ExamplesList';
import ExampleWidget from './ExampleWidget';

but when sorted with case sensitivity:

import ExampleComponent from './ExampleComponent';
import ExampleWidget from './ExampleWidget';
import ExamplesList from './ExamplesList';

To me, the case-sensitive sort makes a lot more sense. After all, in Javascript/Typescript, CamelCase is used basically everywhere (and camel case is really the motivating reason behind the implementation of this case sensitive sort).