Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support explicit type sorting #44

Merged
merged 3 commits into from Oct 27, 2022
Merged

Support explicit type sorting #44

merged 3 commits into from Oct 27, 2022

Conversation

IanVS
Copy link
Owner

@IanVS IanVS commented Oct 26, 2022

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
Copy link
Owner Author

IanVS commented Oct 26, 2022

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

If you would like to order type imports differently from value imports, you can use the special `<TYPES>` string. This example will place third party types at the top, followed by local types, then third party value imports, and lastly local value imports:

```json
"importOrder": ["<TYPES>", "<TYPES>^[./]", "<THIRD_PARTY_MODULES>", "^[./]"],
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Owner Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Owner Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

@IanVS IanVS merged commit 35266d5 into main Oct 27, 2022
6 checks passed
@IanVS IanVS deleted the type-import-control branch October 27, 2022 17:36
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Type imports
2 participants