-
-
Notifications
You must be signed in to change notification settings - Fork 472
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
feat(linter): create the import/order rule #7903
base: main
Are you sure you want to change the base?
Conversation
all cases are not covered bu the architecture is setup
How to use the Graphite Merge QueueAdd either label to this PR to merge it via the merge queue:
You must have a Graphite account in order to use the merge queue. Sign up using this link. An organization admin has enabled the Graphite Merge Queue in this repository. Please do not merge from GitHub as this will restart CI on PRs being processed by the merge queue. |
CodSpeed Performance ReportMerging #7903 will not alter performanceComparing Summary
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It seems like this is for https://github.com/import-js/eslint-plugin-import/blob/main/docs/rules/order.md and not https://eslint.org/docs/latest/rules/sort-imports
Biome also has a separate import sorting step https://biomejs.dev/analyzer/import-sorting/
I wonder what the differences are.
@Spoutnik97 thanks for the work 👍 It feels like you are going to the trouble of making your own file with tests. Please have a look how to setup a new rule: The |
@Sysix oh great! Indeed I didn't know this refreshed list |
@Boshen yes indeed, this is for this rule It seems that differences are you cannot customize the order/groups with biomejs |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
i don't think this snap should be committed
We've also got #7197 which we were considering implementing I would suggest we perhaps make an issue for this with one rule (maybe oxc) to cover all/most cases? my reasoning for this is that we don't really want two rules doing almost the same thing We cam probable remove a few of the config options from |
I just improved the rule by covering more use cases. Indeed, it would be better to don't have duplicate rule effects |
all cases are not covered bu the architecture is setup