Support explicit type sorting

[IanVS]

Closes #35

Adapted from trivago/prettier-plugin-sort-imports#153, by @xenfo.

This adds a new special string, <TYPES> that can be added to the importOrder array. When used, it will cause type imports to be sorted as specified by its location in the array.

Notes:

• If it is used, it will disable importOrderCombineTypeAndValueImports, throwing a warning if both are used. This is because:
• We will split apart type and value import declarations if <TYPES> is used, so that types can be sorted appropriately.
• Thinking towards the next breaking change when we remove options, I think the default will be to enable importOrderCombineTypeAndValueImports, and this change will give users a good way to opt-out of that behavior if they want, by specifying the location for <TYPES>.

[IanVS]

@fbartho @blutorange I'd love to get your thoughts on this change before merging.

[fbartho]

I don't love the "virtual matcher" combined with a custom matcher for Types. "<TYPES>^[./]"
It feels like a bad precedent to have to split these keys into tags and a regex, and have to match them by startsWith, etc.

I don't mind the rest of this PR though! We talked about this feature previously.

[IanVS]

I agree it does feel a bit wonky. Do you have any idea how else we could support it, though? (We don't actually use startsWith here, fwiw, but we do remove the <TYPES> part when creating the regex.

The tricky part here is giving the flexibility to declare a regex as only applying to type imports vs value imports. I think we'd need to support objects in importOrder, and use something like importOrder: [{regex: '^[./]', isType: true}, ...], and that doesn't feel great either. I'm open to suggestions here, though.

[fbartho]

Okay, so thinking about this more deeply, this is supposed to mirror the ability to create arbitrary groups for types. Eg. interleave types and non-type imports in batches.

I'd mayhaps try to argue that as a plugin for an opinionated formatter, maybe we should fight to remove the importOrder option entirely, but that seems like a hard sell.

Fewer customization points = simpler code, and easier onboarding for users, so I guess your original proposal is better than the alternatives that jump to mind.

[IanVS]

Yeah I think that it's okay to keep importOrder and try to minimize the number of other options that we expose. I definitely think we need a default for it that works in most cases, though.