feat: add option followTsOrganizeImports for order rule
#287
Conversation
🦋 Changeset detectedLatest commit: ab4ec1d The changes in this PR will be included in the next version bump. This PR includes changesets to release 1 package
Not sure what this means? Click here to learn what changesets are. Click here if you're a maintainer who wants to add another changeset to this PR |
|
""" WalkthroughThis pull request introduces enhancements to the import ordering system by adding a new option called Changes
Assessment against linked issues
Poem
Warning There were issues while running some tools. Please review the errors and either fix the tool's configuration or disable the tool if it's a critical failure. 🔧 ESLint
test/rules/order.spec.tsOops! Something went wrong! :( ESLint: 9.24.0 Error [ERR_MODULE_NOT_FOUND]: Cannot find module '/lib/index.js' imported from /eslint.config.js Tip ⚡💬 Agentic Chat (Pro Plan, General Availability)
📜 Recent review detailsConfiguration used: CodeRabbit UI 📒 Files selected for processing (1)
🧰 Additional context used🧬 Code Graph Analysis (1)test/rules/order.spec.ts (1)
🪛 GitHub Actions: CItest/rules/order.spec.ts[error] 1-2: ESLint rule '@rule-tester/order' violations: ' ⏰ Context from checks skipped due to timeout of 90000ms (1)
🔇 Additional comments (7)
✨ Finishing Touches
🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments. CodeRabbit Commands (Invoked using PR comments)
Other keywords and placeholders
CodeRabbit Configuration File (
|
|
This pull request is automatically built and testable in CodeSandbox. To see build info of the built libraries, click here or the icon next to each commit SHA. |
Shinigami92
force-pushed
the
fix-ts-organize-imports-mismatch-for-hashtag-imports
branch
from
0c288ff to
bf0887e
Compare
|
@coderabbitai review |
✅ Actions performedReview triggered.
|
Shinigami92
force-pushed
the
fix-ts-organize-imports-mismatch-for-hashtag-imports
branch
from
bf0887e to
e64136f
Compare
|
@JounQin could you please do a first human-review / sanity check and run the GitHub actions workflow? PS: the contribution PR flow is 🚀🤯 ( |
commit: |
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## master #287 +/- ##
=======================================
Coverage 95.99% 96.00%
=======================================
Files 91 91
Lines 4744 4752 +8
Branches 1763 1767 +4
=======================================
+ Hits 4554 4562 +8
Misses 189 189
Partials 1 1 ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
|
Accidentally marked as ready for review. 😅 |
Shinigami92
changed the title
followTsOrganizeImports for order rule
Shinigami92
force-pushed
the
fix-ts-organize-imports-mismatch-for-hashtag-imports
branch
from
53106d8 to
2790318
Compare
|
@JounQin is there anything that is missing that needs to be done before we can merge, except of finding good names? |
![ellipsis-dev[bot]](https://avatars.githubusercontent.com/in/64358?s=60&v=4){kind=small}
There was a problem hiding this comment.
👍 Looks good to me! Reviewed everything up to 2790318 in 1 minute and 34 seconds
More details
- Looked at
200lines of code in5files - Skipped
0files when reviewing. - Skipped posting
11drafted comments based on config settings.
1. test/rules/order.spec.ts:5212
- Draft comment:
The new optionfollowTsOrganizeImportsis being tested and appears to work as intended. The test case here clearly contrasts the expected order when this option is enabled. - Reason this comment was not posted:
Comment did not seem useful. Confidence is useful =0%<= threshold50%
This comment is purely informative, as it only states that a new option is being tested and works as intended. It doesn't provide any actionable feedback or suggestions for improvement.
2. test/rules/order.spec.ts:5410
- Draft comment:
The test suite is very comprehensive. Consider adding inline documentation to explain the intent behind some of the more complex grouping and ordering test cases to aid future maintainers. - Reason this comment was not posted:
Comment was not on a location in the diff, so it can't be submitted as a review comment.
3. test/rules/order.spec.ts:5200
- Draft comment:
The error messages defined withcreateOrderErrorare consistent. Ensure that documentation (if not already updated) reflects the behavior offollowTsOrganizeImportsand any implications on manual group definitions. - Reason this comment was not posted:
Comment was not on a location in the diff, so it can't be submitted as a review comment.
4. test/rules/order.spec.ts:1
- Draft comment:
This test file is extremely comprehensive, covering a wide range of ordering scenarios (import vs require, newlines, comments, whitespace, and even invalid configurations). The extensive coverage is impressive but its size may impact maintainability. - Reason this comment was not posted:
Confidence changes required:0%<= threshold50%
None
5. test/rules/order.spec.ts:4812
- Draft comment:
New test cases for the followTsOrganizeImports option correctly simulate TypeScript’s LSP organize imports. Ensure that future updates continue to conform with TS LSP behavior. - Reason this comment was not posted:
Confidence changes required:0%<= threshold50%
None
6. test/rules/order.spec.ts:1426
- Draft comment:
The tests that handle multiline comments and Windows-style newlines (e.g. around lines 1426–1436) are very valuable. Adding inline comments explaining the intent in such complex blocks would improve maintainability. - Reason this comment was not posted:
Confidence changes required:33%<= threshold50%
None
7. test/rules/order.spec.ts:1588
- Draft comment:
Several tests provide the expected output as an array (supporting multiple valid fix outputs). Consider documenting the precedence rules if multiple correct outputs are possible to ensure deterministic behavior across environments. - Reason this comment was not posted:
Confidence changes required:0%<= threshold50%
None
8. test/rules/order.spec.ts:32
- Draft comment:
The use of helper functions like createOrderError and createGenericError is consistent and aids clarity. Make sure that any future changes to error message text remain synchronized with these tests. - Reason this comment was not posted:
Confidence changes required:0%<= threshold50%
None
9. test/rules/order.spec.ts:500
- Draft comment:
Given the substantial size and complexity of this test file, consider refactoring or splitting the tests into multiple modules (e.g. separating valid and invalid cases) for improved readability and future maintenance. - Reason this comment was not posted:
Confidence changes required:50%<= threshold50%
None
10. test/rules/order.spec.ts:5243
- Draft comment:
The tests that run under different parser configurations (including TypeScript and Flow) confirm robust integration. This is particularly important for validating the new followTsOrganizeImports option. Consistency across these setups is well maintained. - Reason this comment was not posted:
Confidence changes required:0%<= threshold50%
None
11. src/utils/import-type.ts:57
- Draft comment:
Typo Alert: In the isExternalModuleMain function (lines 57-61), the error message mentions 'name, path, and context' as required parameters, but the parameter is actually named 'modulePath'. Consider updating the error string to 'name, modulePath, and context are all required' for clarity. - Reason this comment was not posted:
Comment was not on a location in the diff, so it can't be submitted as a review comment.
Workflow ID: wflow_qiWlP2CypJt5qQzq
You can customize Ellipsis with 👍 / 👎 feedback, review rules, user-specific overrides, quiet mode, and more.
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 0
♻️ Duplicate comments (2)
src/rules/order.ts (2)
836-836: 🛠️ Refactor suggestionUpdate type name to be consistent with other type names.
The type name 'private' should be renamed to 'private-import' to maintain consistency with other singular type names in the array.
- 'private', + 'private-import',
1407-1414: 🛠️ Refactor suggestionUse ESLint reporting instead of debug logs for configuration warnings.
Currently, you're using the debug logger to warn about incompatible configurations, which most users won't see. A more user-friendly approach would be to use ESLint's reporting mechanism.
Based on a previous discussion, consider using the existing
logfunction for now, but the message could be more explicit:if (options.followTsOrganizeImports && options.groups) { // TODO: remove warning when default of followTsOrganizeImports switched to true // because then the user potentially knows what they are doing // and the warning is not needed anymore log( - '`followTsOrganizeImports: true` has no effect when custom `groups` are defined.', + 'When `followTsOrganizeImports: true` is used with custom `groups`, the TypeScript ordering is ignored in favor of your custom groups.', ) }
🧹 Nitpick comments (1)
src/rules/order.ts (1)
56-63: The new import order differs from existing defaults.The new
defaultGroupsTsOrganizeImportsconstant defines an order that's significantly different from the default groups. This reordering appears to be intentional to match TypeScript's LSP Organize Imports behavior, but could use a code comment explaining the specific ordering rationale.const defaultGroupsTsOrganizeImports = [ 'private', 'external', 'builtin', 'parent', 'index', 'sibling', + // Order follows TypeScript's LSP Organize Imports behavior: + // 1. Private imports (starting with #) + // 2. External dependencies + // 3. Built-in Node.js modules + // 4. Parent/ancestor imports + // 5. Index imports + // 6. Sibling imports ] as const
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (2)
.changeset/proud-comics-trade.md(1 hunks)src/rules/order.ts(5 hunks)
⏰ Context from checks skipped due to timeout of 90000ms (21)
- GitHub Check: Lint and Test with Node.js 22 and ESLint 9 on windows-latest
- GitHub Check: Lint and Test with Node.js 20 and ESLint 9 on windows-latest
- GitHub Check: Lint and Test with Node.js 22 and ESLint 8 on windows-latest
- GitHub Check: Lint and Test with Node.js 18 and ESLint 9 on windows-latest
- GitHub Check: Lint and Test with Node.js 20 and ESLint 8.56 on windows-latest
- GitHub Check: Lint and Test with Node.js 22 and ESLint 8.56 on windows-latest
- GitHub Check: Lint and Test with Node.js 18 and ESLint 8 on windows-latest
- GitHub Check: Lint and Test with Node.js 20 and ESLint 8 on windows-latest
- GitHub Check: Lint and Test with Node.js 18 and ESLint 8.56 on windows-latest
- GitHub Check: Lint and Test with Node.js 18 and ESLint 8 on ubuntu-latest
- GitHub Check: Lint and Test with Node.js 18 and ESLint 9 on ubuntu-latest
- GitHub Check: Lint and Test with Node.js 22 and ESLint 9 on ubuntu-latest
- GitHub Check: Lint and Test with Node.js 20 and ESLint 8.56 on ubuntu-latest
- GitHub Check: Lint and Test with Node.js 18 and ESLint 8.56 on ubuntu-latest
- GitHub Check: Lint and Test with Node.js 22 and ESLint 8.56 on ubuntu-latest
- GitHub Check: Lint and Test with Node.js 20 and ESLint 8 on macos-latest
- GitHub Check: Lint and Test with Node.js 18 and ESLint 8 on macos-latest
- GitHub Check: Lint and Test with Node.js 20 and ESLint 8.56 on macos-latest
- GitHub Check: Lint and Test with Node.js 18 and ESLint 9 on macos-latest
- GitHub Check: Lint and Test with Node.js 22 and ESLint 8.56 on macos-latest
- GitHub Check: Codacy Static Code Analysis
🔇 Additional comments (4)
.changeset/proud-comics-trade.md (1)
1-6: LGTM: Clear and concise changelog entry for the feature.The entry correctly documents the new usable group
privatefor theorderrule in a clear and concise manner.src/rules/order.ts (3)
1162-1162: LGTM: Adding new option for TypeScript import organization.The new
followTsOrganizeImportsoption is well-named and properly added to the Options interface, with a good default value and a TODO comment about future default changes.
1285-1289: Clear schema definition for the new option.The schema definition for
followTsOrganizeImportsis well-structured and includes appropriate type information and default value. The comment about changing the default in the next major version is helpful.
1415-1420: LGTM: Good conditional selection of import groups.The code properly selects between the default groups and the new TypeScript-compatible groups based on the
followTsOrganizeImportsoption. This implementation ensures backward compatibility while providing the new functionality.
Shinigami92
force-pushed
the
fix-ts-organize-imports-mismatch-for-hashtag-imports
branch
from
bf9db5a to
213eb21
Compare
There was a problem hiding this comment.
👍 Looks good to me! Reviewed everything up to 923ffb4 in 3 minutes and 16 seconds
More details
- Looked at
293lines of code in6files - Skipped
0files when reviewing. - Skipped posting
11drafted comments based on config settings.
1. test/rules/order.spec.ts:4813
- Draft comment:
Excellent test coverage for the new followTsOrganizeImports option. The tests correctly verify both the enabled and disabled behavior, as well as that manual groups override the followTsOrganizeImports setting. - Reason this comment was not posted:
Confidence changes required:0%<= threshold50%
None
2. test/rules/order.spec.ts:4831
- Draft comment:
Good: The explicit test for followTsOrganizeImports=false confirms expected ordering without TS LSP semantics. - Reason this comment was not posted:
Confidence changes required:0%<= threshold50%
None
3. test/rules/order.spec.ts:4850
- Draft comment:
Nice: The manual groups test shows that custom group settings override followTsOrganizeImports as required. - Reason this comment was not posted:
Confidence changes required:0%<= threshold50%
None
4. test/rules/order.spec.ts:1
- Draft comment:
The test file is extensive and covers many scenarios; consider using a dedent helper for multi-line template literals to improve readability. - Reason this comment was not posted:
Confidence changes required:33%<= threshold50%
None
5. test/rules/order.spec.ts:4813
- Draft comment:
The new valid test case using { followTsOrganizeImports: true } clearly illustrates that '#'‐prefixed imports are shifted to the top per TS LSP organize imports. This test is clear and covers the expected behavior. - Reason this comment was not posted:
Comment did not seem useful. Confidence is useful =0%<= threshold50%
This comment is purely informative, as it only praises the addition of a test case without providing any actionable feedback or suggestions for improvement. It does not align with the rules for good comments, which should offer specific suggestions or highlight potential issues.
6. test/rules/order.spec.ts:4831
- Draft comment:
The test with explicit followTsOrganizeImports set to false correctly confirms that the default ordering is preserved when this option is disabled. - Reason this comment was not posted:
Comment did not seem useful. Confidence is useful =0%<= threshold50%
This comment is purely informative, as it simply states that a test is working as expected. It does not provide any actionable feedback or suggestions for improvement.
7. test/rules/order.spec.ts:4850
- Draft comment:
Good test coverage: the manual groups test confirms that explicitly set groups take precedence over the followTsOrganizeImports option. This reinforces correct prioritization. - Reason this comment was not posted:
Comment did not seem useful. Confidence is useful =0%<= threshold50%
This comment is purely informative, as it praises the test coverage without providing any actionable feedback or suggestions for improvement. It does not align with the rules for acceptable comments.
8. test/rules/order.spec.ts:5254
- Draft comment:
The invalid test case demonstrating a reordering error under followTsOrganizeImports: true is well constructed. It shows that '#'‐prefixed imports must be ordered before other groups as expected by TS’s organize imports behavior. - Reason this comment was not posted:
Comment did not seem useful. Confidence is useful =0%<= threshold50%
This comment is purely informative, praising the construction of a test case. It does not provide any actionable feedback or suggestions for improvement.
9. test/rules/order.spec.ts:5270
- Draft comment:
Overall, the test suite now covers multiple combinations for the followTsOrganizeImports option. Consider adding a brief test to check the default behavior when the option is omitted. - Reason this comment was not posted:
Decided after close inspection that this draft comment was likely wrong and/or not actionable: usefulness confidence = 20% vs. threshold = 50%
While having test coverage for omitted options can be valuable, in this case:
- The default behavior is already implicitly tested by the false case
- The comment is asking for verification rather than pointing out a clear issue
- The existing tests cover both true and false cases which effectively tests the behavior boundaries
The comment does identify a gap in explicit test coverage. Having a test for the omitted case could make the behavior more obvious to readers.
However, this is a "nice to have" rather than a critical issue. The behavior is already well tested through the existing cases. The comment is more of a suggestion than identifying a real problem.
The comment should be deleted as it's asking for optional additional test coverage rather than identifying a clear issue that needs to be fixed.
10. docs/rules/order.md:169
- Draft comment:
Typo: Consider changing "If the import's specifier is starting with#" to "If the import's specifier starts with#" for improved clarity and grammatical correctness. - Reason this comment was not posted:
Decided after close inspection that this draft comment was likely wrong and/or not actionable: usefulness confidence = 10% vs. threshold = 50%
Looking at the context, this is a documentation file explaining import ordering rules. The suggested change would improve readability and maintain consistency with other similar statements in the numbered list. However, the current wording is still understandable and the change is very minor. The rules say not to make purely informative comments or obvious changes.
The change would improve the documentation quality, but it's a very minor grammatical fix that doesn't affect functionality. The current wording is still clear enough to understand.
While the suggestion would improve the text, it's too minor of an issue to warrant a PR comment. Documentation polish can be handled in dedicated documentation review passes.
Delete this comment as it suggests a very minor grammatical improvement that doesn't materially affect understanding of the documentation.
11. docs/rules/order.md:67
- Draft comment:
Typographical error: There is an extraneous diacritical mark (̀) beforebabel-register. Please remove it so it reads simply as "Allowed asbabel-registeris not assigned." - Reason this comment was not posted:
Comment was not on a location in the diff, so it can't be submitted as a review comment.
Workflow ID: wflow_fe00QHHiUAX9pGFq
You can customize Ellipsis with 👍 / 👎 feedback, review rules, user-specific overrides, quiet mode, and more.
There was a problem hiding this comment.
Actionable comments posted: 0
♻️ Duplicate comments (1)
src/rules/order.ts (1)
836-836: 🛠️ Refactor suggestionUpdate type name to be consistent with other type names
The type name 'private' should be renamed to 'private-import' to maintain consistency with other singular type names in the array.
- 'private', + 'private-import',This change would align with the consensus from previous discussions in PR comments.
🧹 Nitpick comments (1)
src/rules/order.ts (1)
1408-1411: Conditional selection of import groups is implemented correctly.The logic to conditionally use
defaultGroupsTsOrganizeImportsinstead ofdefaultGroupswhenfollowTsOrganizeImportsis true is well implemented.However, based on the PR comments, there was a discussion about warning users when they define their own groups along with
followTsOrganizeImports: true. Consider implementing this warning mechanism to improve user experience.const { pathGroups, maxPosition } = convertPathGroupsForRanks( options.pathGroups || [], ) +if (options.followTsOrganizeImports && options.groups) { + log( + 'If you have defined your own `groups` in `order`, `followTsOrganizeImports: true` has no effect.', + ) +} const { groups, omittedTypes } = convertGroupsToRanks( options.groups || (options.followTsOrganizeImports ? defaultGroupsTsOrganizeImports : defaultGroups), )
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (1)
src/rules/order.ts(5 hunks)
⏰ Context from checks skipped due to timeout of 90000ms (1)
- GitHub Check: Codacy Static Code Analysis
🔇 Additional comments (3)
src/rules/order.ts (3)
56-63: The default TypeScript organize imports order looks good.This constant defines the order of imports to match TypeScript's LSP Organize Imports behavior, correctly positioning 'private' imports first, followed by external, builtin, and internal imports in the expected order.
1162-1162: Interface addition looks good.The new
followTsOrganizeImportsoption is correctly added to the Options interface as an optional boolean property.
1285-1289: Schema definition is well structured.The schema validation for the new option is correctly added with appropriate type and default value. The TODO comment about changing the default in the next major version is a good practice for maintaining backward compatibility.
test/fixtures/typescript-order-custom-paths-mapping/tsconfig-with-path-mapping.json
Show resolved
Hide resolved
![graphite-app[bot]](https://avatars.githubusercontent.com/in/158384?s=60&v=4){kind=small}
| const defaultGroupsTsOrganizeImports = [ | ||
| 'private', | ||
| 'external', | ||
| 'builtin', | ||
| 'parent', | ||
| 'index', | ||
| 'sibling', | ||
| ] as const |
There was a problem hiding this comment.
The order in defaultGroupsTsOrganizeImports appears to be inconsistent with TypeScript's LSP Organize Imports behavior. Based on the tests and documentation, TypeScript organizes imports with 'builtin' modules before 'external' modules, but this implementation has 'external' before 'builtin'. Consider swapping these two entries to match TypeScript's actual ordering behavior.
| const defaultGroupsTsOrganizeImports = [ | |
| 'private', | |
| 'external', | |
| 'builtin', | |
| 'parent', | |
| 'index', | |
| 'sibling', | |
| ] as const | |
| const defaultGroupsTsOrganizeImports = [ | |
| 'private', | |
| 'builtin', | |
| 'external', | |
| 'parent', | |
| 'index', | |
| 'sibling', | |
| ] as const |
Spotted by Diamond
Is this helpful? React 👍 or 👎 to let us know.
There was a problem hiding this comment.
@Shinigami92 Can you double check?
There was a problem hiding this comment.
I also think builtin should be front of external.
There was a problem hiding this comment.
I'll check, but my gut feeling tells me either we missed a import-statement case, or it works correctly right now already and the AI is hallucinating
There was a problem hiding this comment.
AH! so an external import is something like e.g. glob 👍
Will add to test
There was a problem hiding this comment.
Do you want to get a test case for separated node:* with followTsOrganizeImports: true?
There was a problem hiding this comment.
I mean, you can still have all your node:* imports at the top if you but it in a separate group (split them with a newline from the other imports)
Wouldn't the group order be different?
Do you want to get a test case for separated
node:*withfollowTsOrganizeImports: true?
Thta's would be appreciated.
There was a problem hiding this comment.
Wouldn't the group order be different?
No, why should it?
That's would be appreciated.
Added ab4ec1d (#287)
You should take a case like I added here, and copy-paste it into your VSCode and then hit CTRL+SHIFT+P and run organize imports, then you can experiment yourself a bit with it 🙂
There was a problem hiding this comment.
Finally we got failing test cases, I don't know whether it's expected to you.
There was a problem hiding this comment.
No, why should it?
Didn't the default order external should be listed in front of builtin as you set? Did I miss anything?
You should take a case like I added here, and copy-paste it into your VSCode and then hit CTRL+SHIFT+P and run organize imports, then you can experiment yourself a bit with it 🙂
I also use this command a lot when I develop projects not using this plugin nor simple-sort-imports, etc, for example: https://github.com/backstage/backstage.
|
| // test followTsOrganizeImports: true and splitted node:* group | ||
| tValid({ | ||
| code: `import fs from 'node:fs'; | ||
| import path from "path"; | ||
|
|
||
| import { internA } from "#a"; | ||
| import { privateA } from "#private/a"; | ||
| import { scopeA } from "@a/a"; | ||
| import a from 'a'; | ||
| import 'format.css'; | ||
| import { glob } from 'glob'; | ||
| import index from './'; | ||
| import { localA } from "./a"; | ||
| import sibling from './foo'; | ||
| `, | ||
| ...parserConfig, | ||
| options: [ | ||
| { | ||
| followTsOrganizeImports: true, | ||
| }, | ||
| ], | ||
| }), |
There was a problem hiding this comment.
todo: test case is failing 👀
I will investigate
There was a problem hiding this comment.
Finally we got the failing test case. 🤣
There was a problem hiding this comment.
Okay, it looks like the code is not prepared to allow groups separated from each other without affecting each other. Due to I spend now a lot of time into this, I think I need to first dig deeper into the code and e.g. prepare myself with the other mentioned PR to add JSDocs, because right now it is really hard to understand whats going on and you need to often switch between docs and code instead of just reading from the code.
My personal case would be fixed/satisfied by the current implementation, because I never separate imports into groups and just trust the TS LSP by doing its thing. But I came in conflict with the 'import-x/order': 'error' rule, because by default the #-imports conflicts with the LSP in the default case. So I come constantly in conflict in a project with a coworker right now, because he wants to use the eslint rule default and I want to use the TS LSP default..., and IMO at least the both in combination should not at least conflict by default.
But yes, you are right in the sense of if now someone else would group their imports into 'node:*' having at the top, the LSP would not trigger, but the eslint rule would now trigger. 🫠 But was it like this also before?
If I overlook something right now, please hint me in the right direction what I need to touch to allow separate groups without affecting each other.
Otherwise, see you after 28th April 🚗-🇮🇸-😎
There was a problem hiding this comment.
But was it like this also before?
It could be, node: is only supported in a short time at import-js#3173 which we haven't adopted into this fork yet, so testing for it is lacking right now.
In my experience, TS LSP only sort imports in same group, what means if there is no lines between imports then they will be sorted, when there are new lines between imports, they're considered different groups by TS LSP and will not be sorted, so I think private is not a group now, it should be ranked if only in same group which is here
eslint-plugin-import-x/src/rules/order.ts
Lines 606 to 661 in 95dd356
Otherwise, see you after 28th April 🚗-🇮🇸-😎
Feel free to take a break, have a good time!
closes #286
Summary by CodeRabbit
followTsOrganizeImportsfor the import ordering rule, enhancing control over import statement organization.privatefor import classification.followTsOrganizeImportsoption, detailing its behavior and implications.Important
Add
followTsOrganizeImportsoption andprivateimport type toorderrule, updating documentation and tests.followTsOrganizeImportsoption toorderrule inorder.ts, aligning import order with TypeScript's LSP Organize Imports.privateimport type for imports starting with#inimport-type.ts.order.mdto includefollowTsOrganizeImportsandprivateimport type.order.spec.tsto validatefollowTsOrganizeImportsandprivateimport type behavior.This description was created by
for 923ffb4. It will automatically update as commits are pushed.