feat: export flat configs in configs object #350
Conversation
ESLint doesn't understand what `flatConfigs` is, the actual config object is `configs`. So we need to expose the flat configs there in order for ESLint's `extends` logic to work properly. This means `extends: ['import-x/recommended']` will now work.
🦋 Changeset detectedLatest commit: e5e1de5 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 change updates the Changes
Sequence Diagram(s)sequenceDiagram
participant User
participant Plugin
participant ESLint
User->>Plugin: Import plugin and reference configs
Plugin->>Plugin: Expose configs (legacy + flat) via `configs` property
Plugin->>ESLint: Provide selected config object(s)
ESLint->>ESLint: Apply configuration to linting process
Possibly related PRs
Suggested labels
Suggested reviewers
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
src/index.tsOops! Something went wrong! :( ESLint: 9.27.0 Error [ERR_MODULE_NOT_FOUND]: Cannot find module '/lib/index.js' imported from /eslint.config.js .eslint-doc-generatorrc.jsOops! Something went wrong! :( ESLint: 9.27.0 Error [ERR_MODULE_NOT_FOUND]: Cannot find module '/lib/index.js' imported from /eslint.config.js 📜 Recent review detailsConfiguration used: CodeRabbit UI 📒 Files selected for processing (15)
🧰 Additional context used🧬 Code Graph Analysis (1)src/index.ts (1)
🪛 LanguageToolREADME.md[duplication] ~259-~259: Possible typo: you repeated a word. (ENGLISH_WORD_REPEAT_RULE) [duplication] ~283-~283: Possible typo: you repeated a word. (ENGLISH_WORD_REPEAT_RULE) [duplication] ~284-~284: Possible typo: you repeated a word. (ENGLISH_WORD_REPEAT_RULE) [duplication] ~284-~284: Possible typo: you repeated a word. (ENGLISH_WORD_REPEAT_RULE) [duplication] ~285-~285: Possible typo: you repeated a word. (ENGLISH_WORD_REPEAT_RULE) [duplication] ~294-~294: Possible typo: you repeated a word. (ENGLISH_WORD_REPEAT_RULE) ⏰ Context from checks skipped due to timeout of 90000ms (46)
🔇 Additional comments (19)
✨ Finishing Touches
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. 🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
SupportNeed help? Create a ticket on our support page for assistance with any issues or questions. 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 (
|
WalkthroughThis pull request addresses an issue where ESLint does not recognize Changes
|
![petercat-assistant[bot]](https://avatars.githubusercontent.com/in/875736?s=60&v=4){kind=small}
|
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. |
commit: |
![ellipsis-dev[bot]](https://avatars.githubusercontent.com/in/64358?s=60&v=4){kind=small}
There was a problem hiding this comment.
Caution
Changes requested ❌
Reviewed everything up to 155eb82 in 1 minute and 28 seconds. Click for details.
- Reviewed
98lines of code in2files - Skipped
0files when reviewing. - Skipped posting
4draft comments. View those below. - Modify your settings and rules to customize what types of comments Ellipsis leaves. And don't forget to react with 👍 or 👎 to teach Ellipsis.
1. .changeset/smooth-horses-greet.md:5
- Draft comment:
The changeset message clearly describes the intent to expose flat configs in the 'configs' object. - Reason this comment was not posted:
Confidence changes required:0%<= threshold50%None
2. src/index.ts:135
- Draft comment:
Removing the legacy 'configs' property from the initial plugin_ object avoids potential circular references and keeps config exposure centralized. - Reason this comment was not posted:
Comment did not seem useful. Confidence is useful =0%<= threshold50%This comment is purely informative, explaining the reason behind a change without suggesting any action or asking for confirmation. It doesn't align with the rules for useful comments.
3. src/index.ts:150
- Draft comment:
Switching from 'plugin' to 'plugin_' in createFlatConfig avoids a circular dependency by not referencing the not-yet-extended plugin object. - Reason this comment was not posted:
Comment did not seem useful. Confidence is useful =0%<= threshold50%This comment is informative, explaining why a change was made to avoid a circular dependency. It doesn't ask for confirmation or suggest any changes.
4. src/index.ts:194
- Draft comment:
Extending the plugin object via a type cast to include both flatConfigs and configs improves clarity and aligns with ESLint's expectations. - Reason this comment was not posted:
Comment did not seem useful. Confidence is useful =0%<= threshold50%This comment is purely informative and does not provide any actionable feedback or suggestions for improvement. It simply praises the change without offering any specific guidance or questions.
Workflow ID: wflow_5hFmLsIa2LdXgSQo
You can customize 
Coverage summary from CodacySee diff coverage on Codacy
Coverage variation details
Coverage variation is the difference between the coverage for the head and common ancestor commits of the pull request branch: Diff coverage details
Diff coverage is the percentage of lines that are covered by tests out of the coverable lines that the pull request added or modified: See your quality gate settings Change summary preferences |
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## master #350 +/- ##
=======================================
Coverage 96.27% 96.27%
=======================================
Files 92 92
Lines 4835 4836 +1
Branches 1823 1825 +2
=======================================
+ Hits 4655 4656 +1
Misses 179 179
Partials 1 1 ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
There was a problem hiding this comment.
Important
Looks good to me! 👍
Reviewed cd90feb in 45 seconds. Click for details.
- Reviewed
30lines of code in1files - Skipped
0files when reviewing. - Skipped posting
1draft comments. View those below. - Modify your settings and rules to customize what types of comments Ellipsis leaves. And don't forget to react with 👍 or 👎 to teach Ellipsis.
1. README.md:167
- Draft comment:
The newdefineConfigsnippet is clear and correctly demonstrates using flat configs (e.g. 'import-x/flat/recommended'). Nice update! - Reason this comment was not posted:
Confidence changes required:0%<= threshold50%None
Workflow ID: wflow_86zbixDHke7lSUnw
You can customize
![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
🧹 Nitpick comments (3)
docs/rules/named.md (1)
3-3: Separate enabled & disabled icons for clarity
The header prefixes both “💼” and “🚫” at once, which can be misleading. Consider splitting the icons: use “💼” before the enabled list and “🚫” before the disabled list.README.md (2)
140-142: Fix grammatical number agreement in note
Change “configuration” to “configurations” for correct plural form.- > [!NOTE] - > A complete list of available configuration can be found in [config/flat folders](src/config/flat) + > [!NOTE] + > A complete list of available configurations can be found in [config/flat folders](src/config/flat)
165-182: Suggest using the exportedflatConfigsobject directly
To demonstrate the newly exposedflatConfigs, consider extending using the imported object instead of a string literal:- extends: ['import-x/flat/recommended'], + extends: [importX.flatConfigs.recommended],This showcases the plugin’s
flatConfigsexport in action.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (11)
README.md(6 hunks)docs/rules/default.md(1 hunks)docs/rules/export.md(1 hunks)docs/rules/named.md(1 hunks)docs/rules/namespace.md(1 hunks)docs/rules/no-deprecated.md(1 hunks)docs/rules/no-duplicates.md(1 hunks)docs/rules/no-named-as-default-member.md(1 hunks)docs/rules/no-named-as-default.md(1 hunks)docs/rules/no-rename-default.md(1 hunks)docs/rules/no-unresolved.md(1 hunks)
🧰 Additional context used
🪛 markdownlint-cli2 (0.17.2)
README.md
189-189: Blank line inside blockquote
null
(MD028, no-blanks-blockquote)
⏰ Context from checks skipped due to timeout of 90000ms (20)
- GitHub Check: Lint and Test with Node.js 18 and ESLint 8 on windows-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 24 and ESLint 8.56 on windows-latest
- GitHub Check: Lint and Test with Node.js 24 and ESLint 8 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 20 and ESLint 8.56 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 20 and ESLint 8 on ubuntu-latest
- GitHub Check: Lint and Test with Node.js 24 and ESLint 9 on ubuntu-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 22 and ESLint 8 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 9 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 18 and ESLint 8.56 on ubuntu-latest
- GitHub Check: Lint and Test with Node.js 22 and ESLint 9 on macos-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.56 on macos-latest
- GitHub Check: Lint and Test with Node.js 20 and ESLint 9 on macos-latest
- GitHub Check: Lint and Test with Node.js 18 and ESLint 9 on macos-latest
🔇 Additional comments (10)
docs/rules/no-rename-default.md (1)
3-3: Docs: Clarify warning presets to include flat variant
The update correctly expands the rule’s warning contexts to bothflat/warningsand the legacywarningspreset, matching the newly exposed flat configurations.docs/rules/no-named-as-default.md (1)
3-3: Ensure documentation consistency for flat configs
The addition offlat/recommendedandflat/warningsaligns this rule’s docs with the new flat config exports. Please verify that all other rule documentation underdocs/rules/has been updated similarly to include theflat/prefixes where appropriate.docs/rules/no-named-as-default-member.md (1)
3-3: Expose flat configuration presets.
The addition offlat/recommendedandflat/warningsaligns this rule’s documentation with the newly exported flat configs, ensuring ESLint users can reference the correct presets.docs/rules/export.md (1)
3-3: Rule activation configs updated to include flat configurationsThe list of enabled configurations now correctly includes
flat/errorsandflat/recommended, aligning with the newconfigs.flatConfigsexposure insrc/index.ts. Documentation formatting remains consistent.docs/rules/default.md (1)
3-3: Default import rule now enabled in flat configsThe metadata for the
import-x/defaultrule has been expanded to includeflat/errorsandflat/recommended. This matches the plugin’s updatedconfigsobject and maintains consistency with other rule docs.docs/rules/namespace.md (1)
3-3: Namespace rule activation extended to flat configsThe
import-x/namespacerule header now accurately listsflat/errorsandflat/recommendedalongside the existing presets. This aligns the documentation with the plugin’s new flat configuration exposure.docs/rules/no-unresolved.md (1)
3-3: No-unresolved rule enabled in flat configurationsThe rule header for
import-x/no-unresolvedcorrectly addsflat/errorsandflat/recommendedto its activation list, matching theconfigsobject update.docs/rules/no-duplicates.md (1)
3-3: No-duplicates rule warnings extended to flat configsThe warning presets for
import-x/no-duplicatesnow includeflat/recommendedandflat/warnings, ensuring consistency with the plugin’s flat configuration support.docs/rules/named.md (1)
3-3: Documentation accurately reflects new flat configs
The additionsflat/errorsandflat/recommendedin the enabled list (and disabledflat/typescript/typescript) align with the update.docs/rules/no-deprecated.md (1)
3-3: New warning note is accurate
The added line correctly documents that this rule warns in theflat/stage-0config, aligning with the PR objectives.
There was a problem hiding this comment.
Actionable comments posted: 0
🧹 Nitpick comments (1)
README.md (1)
165-182: Add TOC entry for the newdefineConfigsection and align the example with other flat configs
The new “Configuration (usingdefineConfig)” section is a valuable addition, but it’s not yet linked in the table of contents. Also, for consistency with the other flat‐config examples, consider referencing theflatConfigsobject directly instead of a string literal.--- README.md @@ -28,6 +28,7 @@ - [As a standalone ESLint plugin](#as-a-standalone-eslint-plugin) + - [Configuration (using `defineConfig`)](#configuration-using-defineconfig) - [Configuration (legacy: `.eslintrc*`)](#configuration-legacy-eslintrc)--- README.md @@ -176,7 +176,7 @@ plugins: { 'import-x': importX, }, - extends: ['import-x/flat/recommended'], + extends: [importX.flatConfigs.recommended], rules: { 'import-x/no-dynamic-require': 'warn', },
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (1)
README.md(3 hunks)
🧰 Additional context used
🪛 LanguageTool
README.md
[uncategorized] ~314-~314: You might be missing the article “a” here.
Context: ... | Prefer a default export if module exports a single name or multiple names...
(AI_EN_LECTOR_MISSING_DETERMINER_A)
⏰ Context from checks skipped due to timeout of 90000ms (20)
- 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 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 20 and ESLint 9 on ubuntu-latest
- GitHub Check: Lint and Test with Node.js 24 and ESLint 8 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 22 and ESLint 8.56 on windows-latest
- GitHub Check: Lint and Test with Node.js 24 and ESLint 8.56 on ubuntu-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 24 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 18 and ESLint 9 on windows-latest
- GitHub Check: Lint and Test with Node.js 22 and ESLint 8 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 on ubuntu-latest
- GitHub Check: Lint and Test with Node.js 24 and ESLint 8 on macos-latest
- GitHub Check: Lint and Test with Node.js 22 and ESLint 8 on macos-latest
- GitHub Check: Lint and Test with Node.js 22 and ESLint 8.56 on macos-latest
- GitHub Check: Lint and Test with Node.js 20 and ESLint 9 on macos-latest
- GitHub Check: Lint and Test with Node.js 18 and ESLint 8.56 on macos-latest
I suppose you mean |
There was a problem hiding this comment.
Important
Looks good to me! 👍
Reviewed 040c4f8 in 1 minute and 43 seconds. Click for details.
- Reviewed
45lines of code in1files - Skipped
0files when reviewing. - Skipped posting
5draft comments. View those below. - Modify your settings and rules to customize what types of comments Ellipsis leaves. And don't forget to react with 👍 or 👎 to teach Ellipsis.
1. README.md:137
- Draft comment:
Changed admonition marker syntax from “[!NOTE]” to "> [!NOTE]". Please confirm that the added blockquote (>) and escaping of brackets render as intended in your documentation. - Reason this comment was not posted:
Comment did not seem useful. Confidence is useful =0%<= threshold50%The comment is asking the PR author to confirm the rendering of a syntax change in documentation. This falls under asking the author to confirm their intention or to ensure the behavior is intended, which is against the rules.
2. README.md:183
- Draft comment:
Admonition markers like [!TIP], [!NOTE], and [!WARNING] are now prefixed with a blockquote (>) and have their brackets escaped. Ensure this formatting is consistent and renders correctly across all environments. - Reason this comment was not posted:
Comment did not seem useful. Confidence is useful =0%<= threshold50%This comment is purely informative and asks the author to ensure consistency and correct rendering, which violates the rules. It doesn't provide a specific suggestion or point out a specific issue with the code.
3. README.md:340
- Draft comment:
The warning admonition marker was updated from “[!warning]” to "> [!warning]". Verify that this change maintains the intended styling and clarity in the documentation. - Reason this comment was not posted:
Comment did not seem useful. Confidence is useful =0%<= threshold50%This comment is asking the PR author to verify the change, which violates the rule against asking for confirmation or verification of intention. It does not provide a specific suggestion or point out a clear issue with the code.
4. README.md:140
- Draft comment:
Line 140: It appears there is an unnecessary escape character before[!NOTE]. If this is not intentional for proper markdown rendering, please remove the backslash. - Reason this comment was not posted:
Decided after close inspection that this draft comment was likely wrong and/or not actionable: usefulness confidence = 0% vs. threshold = 50% The diff shows a consistent pattern of adding backslashes before these note/tip/warning markers. This is likely an intentional change to properly render these GitHub-style alerts in Markdown. The backslashes are probably necessary for proper rendering. The comment is suggesting to undo what appears to be an intentional change. Could there be a reason why the backslashes were added? Maybe they're needed for proper Markdown rendering on certain platforms. Yes, the backslashes appear to be intentionally added across multiple similar markers in the file, suggesting they serve a purpose for proper Markdown rendering. The comment should be deleted as it's suggesting to undo what appears to be an intentional and consistent change to the Markdown formatting.
5. README.md:219
- Draft comment:
Typo: It looks like there’s an unnecessary backslash before[!WARNING]. If the intention is to render the admonition correctly, please remove the backslash. - Reason this comment was not posted:
Decided after close inspection that this draft comment was likely wrong and/or not actionable: usefulness confidence = 0% vs. threshold = 50% The diff shows multiple instances where backslashes were intentionally added before admonition tags. This appears to be a deliberate change to the formatting. The comment suggests undoing one of these changes, which would break consistency. Since this is a pattern being applied across the file, the backslash is likely intentional and serves some purpose. I could be wrong about the purpose of the backslashes - maybe they really are unnecessary. However, the consistent pattern of adding them suggests they serve some function. Given that this is a systematic change across the file and appears intentional, suggesting to remove the backslash would likely be counterproductive. The comment should be deleted as it suggests undoing what appears to be an intentional formatting change that is being consistently applied throughout the file.
Workflow ID: wflow_iP5P7PbacMBIAmmx
You can customize
JounQin
force-pushed
the
configs-names
branch
2 times, most recently
from
c5a1261 to
0297826
Compare
There was a problem hiding this comment.
Important
Looks good to me! 👍
Reviewed 0297826 in 1 minute and 17 seconds. Click for details.
- Reviewed
62lines of code in1files - Skipped
0files when reviewing. - Skipped posting
8draft comments. View those below. - Modify your settings and rules to customize what types of comments Ellipsis leaves. And don't forget to react with 👍 or 👎 to teach Ellipsis.
1. README.md:29
- Draft comment:
Good TOC update: added 'UsingdefineConfig' improves navigation. - 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 update to the table of contents without providing any actionable feedback or suggestions. It does not align with the rules for useful comments.
2. README.md:138
- Draft comment:
Fix note admonition markup: use '> [!NOTE]' instead of escaped syntax. - Reason this comment was not posted:
Comment looked like it was already resolved.
3. README.md:163
- Draft comment:
Update defineConfig heading for consistency with TOC. - Reason this comment was not posted:
Comment did not seem useful. Confidence is useful =0%<= threshold50%This comment is purely informative, suggesting an update for consistency with the Table of Contents. It doesn't provide a specific code suggestion or highlight a potential issue with the code itself. It doesn't align with the rules for useful comments.
4. README.md:184
- Draft comment:
Correct TIP admonition syntax to '> [!TIP]'. - Reason this comment was not posted:
Comment did not seem useful. Confidence is useful =0%<= threshold50%This comment is purely informative, as it is simply stating the correct syntax for a TIP admonition. It does not provide a suggestion or ask for confirmation about the code's functionality or logic.
5. README.md:187
- Draft comment:
Correct NOTE admonition syntax to '> [!NOTE]'. - Reason this comment was not posted:
Comment did not seem useful. Confidence is useful =0%<= threshold50%This comment is purely informative, as it is just pointing out the correct syntax for a NOTE admonition. It doesn't suggest a change or ask for clarification on the code's intention.
6. README.md:217
- Draft comment:
Fix WARNING admonition: use '> [!WARNING]' for proper rendering. - Reason this comment was not posted:
Comment did not seem useful. Confidence is useful =0%<= threshold50%This comment is purely informative, suggesting a change for proper rendering of a warning admonition. It doesn't ask for a specific code change or test, nor does it point out a potential issue with the code logic. It seems to be more about formatting for documentation purposes.
7. README.md:341
- Draft comment:
Ensure consistent admonition formatting: use '> [!warning]'. - Reason this comment was not posted:
Comment looked like it was already resolved.
8. README.md:142
- Draft comment:
Typo suggestion: Consider updating "available configuration" to "available configurations" (plural) for improved clarity. - Reason this comment was not posted:
Comment was on unchanged code.
Workflow ID: wflow_RNZL4SYnzVvoVmux
You can customize
There was a problem hiding this comment.
Important
Looks good to me! 👍
Reviewed c5a1261 in 1 minute and 56 seconds. Click for details.
- Reviewed
62lines of code in1files - Skipped
0files when reviewing. - Skipped posting
8draft comments. View those below. - Modify your settings and rules to customize what types of comments Ellipsis leaves. And don't forget to react with 👍 or 👎 to teach Ellipsis.
1. README.md:29
- Draft comment:
Nice TOC update with 'UsingdefineConfig'; ensure the section header level stays consistent with the rest of the document. - Reason this comment was not posted:
Confidence changes required:0%<= threshold50%None
2. README.md:138
- Draft comment:
Admonition markers now escaped (e.g. [!NOTE]). Confirm that the target Markdown parser renders these as intended. - Reason this comment was not posted:
Confidence changes required:0%<= threshold50%None
3. README.md:163
- Draft comment:
Heading changed from '## Configuration (usingdefineConfig)' to '### UsingdefineConfig'; verify this level change is intentional. - Reason this comment was not posted:
Confidence changes required:0%<= threshold50%None
4. README.md:184
- Draft comment:
Escaped admonition blocks [!TIP] and [!NOTE] are now shown as > [!TIP] and > [!NOTE]. Confirm that this change displays correctly. - Reason this comment was not posted:
Confidence changes required:0%<= threshold50%None
5. README.md:217
- Draft comment:
The [!WARNING] block is now escaped ([!WARNING]). Ensure that the intended styling is preserved. - Reason this comment was not posted:
Confidence changes required:0%<= threshold50%None
6. README.md:341
- Draft comment:
Admonition [!warning] now appears as > [!warning]. Consider matching the capitalization with other warning blocks for consistency. - Reason this comment was not posted:
Confidence changes required:0%<= threshold50%None
7. README.md:141
- Draft comment:
It appears there's a stray backslash in the note admonition "[!NOTE]". If this is unintentional (and the intent is to have a standard admonition rendered as "[!NOTE]"), please remove the backslash. - Reason this comment was not posted:
Decided after close inspection that this draft comment was likely wrong and/or not actionable: usefulness confidence = 0% vs. threshold = 50% The change to add backslashes appears to be intentional since it was done consistently across multiple admonitions (lines 141, 187, 191, 220). This suggests it's a deliberate styling choice, not a mistake. The comment assumes this is unintentional but provides no evidence for why the unescaped version would be better. The backslashes could be interfering with proper rendering of GitHub note admonitions. I should check if this is a known GitHub markdown syntax requirement. Even if unescaped brackets might work better for GitHub admonitions, the consistent application of backslashes across the file suggests this was an intentional choice by the author. Without strong evidence that this breaks functionality, we should respect the author's formatting choice. Delete the comment since it questions an intentional formatting choice without providing evidence that it causes actual problems.
8. README.md:344
- Draft comment:
Typographical error: It appears that the[!warning]syntax is unintentionally preceded by a backslash (\[!warning]). If this is not intentional, please remove the extra backslash to use the correct syntax. - Reason this comment was not posted:
Decided after close inspection that this draft comment was likely wrong and/or not actionable: usefulness confidence = 0% vs. threshold = 50% Looking at the pattern in the diff, I see that ALL alert block syntax was intentionally changed to add backslashes. This wasn't a typo - it was a deliberate change made consistently throughout the file. The comment is suggesting to undo what appears to be an intentional change. Since this is a UI/documentation change and was done consistently, we should assume the author knows what they're doing. Maybe there's some GitHub Markdown syntax requirement I'm not aware of that makes the backslash incorrect? But even if so, we shouldn't comment on pure documentation formatting. The rules explicitly state not to comment on UI changes and to assume the author made UI changes correctly. This is a pure documentation formatting change. Delete this comment since it's suggesting to undo what appears to be an intentional documentation formatting change, and we're told not to comment on UI/documentation changes.
Workflow ID: wflow_OHXcFVT9bQGhTRbw
You can customize
There was a problem hiding this comment.
Important
Looks good to me! 👍
Reviewed 8a55e21 in 49 seconds. Click for details.
- Reviewed
21lines of code in1files - Skipped
0files when reviewing. - Skipped posting
2draft comments. View those below. - Modify your settings and rules to customize what types of comments Ellipsis leaves. And don't forget to react with 👍 or 👎 to teach Ellipsis.
1. README.md:32
- Draft comment:
TOC update: Added a 'UsingdefineConfig' bullet to match the new config section. Looks good. - Reason this comment was not posted:
Confidence changes required:0%<= threshold50%None
2. README.md:163
- Draft comment:
Updated header level to '### UsingdefineConfig' for consistency with surrounding config examples. - Reason this comment was not posted:
Confidence changes required:0%<= threshold50%None
Workflow ID: wflow_RkoSNiflyanerKRX
You can customize
There was a problem hiding this comment.
Caution
Inline review comments failed to post. This is likely due to GitHub's limits when posting large numbers of comments. If you are seeing this consistently it is likely a permissions issue. Please check "Moderation" -> "Code review limits" under your organization settings.
Actionable comments posted: 3
🧹 Nitpick comments (1)
README.md (1)
315-315: Typo: missing article in description
The description reads “if module exports a single name or multiple names.” It should be “if a module exports…” to include the missing article.-| [prefer-default-export](docs/rules/prefer-default-export.md) | Prefer a default export if module exports a single name or multiple names. | … +| [prefer-default-export](docs/rules/prefer-default-export.md) | Prefer a default export if a module exports a single name or multiple names. | …🧰 Tools
🪛 LanguageTool
[uncategorized] ~315-~315: You might be missing the article “a” here.
Context: ... | Prefer a default export if module exports a single name or multiple names...(AI_EN_LECTOR_MISSING_DETERMINER_A)
🛑 Comments failed to post (3)
README.md (3)
296-316:
⚠️ Potential issueMissing reference definitions for custom badges in the Style guide table
The style guide rows reference![badge-flat/recommended][],![badge-flat/warnings][], etc., yet the README lacks those definitions.Include all needed badge reference links at the bottom of the document.
🧰 Tools
🪛 LanguageTool
[uncategorized] ~315-~315: You might be missing the article “a” here.
Context: ... | Prefer a default export if module exports a single name or multiple names...(AI_EN_LECTOR_MISSING_DETERMINER_A)
🤖 Prompt for AI Agents
In README.md around lines 296 to 316, the style guide table uses custom badge references like ![badge-flat/recommended][] and ![badge-flat/warnings][], but these badge definitions are missing from the document. To fix this, add the corresponding markdown reference definitions for all custom badges used in the table at the bottom of the README file, ensuring each badge name is linked to the correct image URL or resource.
253-264:
⚠️ Potential issueMissing reference definitions for custom badges in the Helpful warnings table
The rows reference badges like![badge-flat/errors][]and![badge-flat/recommended][], but there are no[badge-flat/errors]: ...or[badge-flat/recommended]: ...links later in the document. Without these, the badges won’t render.Please add corresponding reference definitions (e.g., at the bottom of the README) for each custom badge.
🤖 Prompt for AI Agents
In README.md around lines 253 to 264, the markdown table uses custom badge references like ![badge-flat/errors][] and ![badge-flat/recommended][], but the corresponding reference definitions for these badges are missing. To fix this, add the missing badge reference definitions at the bottom of the README file, defining the URLs or image sources for each badge name used in the table, ensuring the badges render correctly.
277-286:
⚠️ Potential issueMissing reference definitions for custom badges in the Static analysis table
This table also uses badge placeholders (e.g.,![badge-flat/errors][]), but their link definitions are absent.Add
[badge-flat/errors]: <badge-URL>and similar entries so the badges display properly.🤖 Prompt for AI Agents
In README.md around lines 277 to 286, the markdown table uses custom badge placeholders like ![badge-flat/errors][] but lacks the corresponding reference link definitions. Add the missing reference definitions for these badges at the bottom of the README or an appropriate section, for example, add lines such as [badge-flat/errors]: <badge-URL> for each badge used to ensure they render correctly.
|
Review the following changes in direct dependencies. Learn more about Socket for GitHub.
|
There was a problem hiding this comment.
Important
Looks good to me! 👍
Reviewed e5e1de5 in 1 minute and 24 seconds. Click for details.
- Reviewed
351lines of code in13files - Skipped
1files when reviewing. - Skipped posting
14draft comments. View those below. - Modify your settings and rules to customize what types of comments Ellipsis leaves. And don't forget to react with 👍 or 👎 to teach Ellipsis.
1. .eslint-doc-generatorrc.js:18
- Draft comment:
The doc generator configuration is concise and follows best practices. Verify that the Prettier options and rule settings meet your project’s formatting needs. - Reason this comment was not posted:
Confidence changes required:0%<= threshold50%None
2. README.md:162
- Draft comment:
Excellent addition of the 'Using defineConfig' section. The provided example is clear—ensure that the admonition markers (e.g. '> [!NOTE]') render correctly in your documentation system. - Reason this comment was not posted:
Confidence changes required:0%<= threshold50%None
3. docs/rules/default.md:3
- Draft comment:
The header now correctly lists both '❗errors' and '❗flat/errors'. This improves clarity. Make sure this symbol usage remains consistent across all rule docs. - Reason this comment was not posted:
Confidence changes required:0%<= threshold50%None
4. docs/rules/export.md:3
- Draft comment:
The configuration info now shows '❗' for flat/errors as well as for errors. This aligns with the updated enforcement across configs. - Reason this comment was not posted:
Confidence changes required:0%<= threshold50%None
5. docs/rules/named.md:3
- Draft comment:
The enabled/disabled config details now consistently use '❗' for flat/errors and '⌨️' for TypeScript variants. Confirm that these symbols match your intended severity levels. - Reason this comment was not posted:
Confidence changes required:0%<= threshold50%None
6. docs/rules/namespace.md:3
- Draft comment:
The namespace rule documentation is comprehensive and consistent with other rules. No issues noted. - Reason this comment was not posted:
Confidence changes required:0%<= threshold50%None
7. docs/rules/no-deprecated.md:1
- Draft comment:
This rule’s header no longer shows explicit config indicators. Confirm that the omission is intentional and that users are aware of its default behavior. - Reason this comment was not posted:
Confidence changes required:33%<= threshold50%None
8. docs/rules/no-duplicates.md:3
- Draft comment:
The rule’s configuration details and examples are well documented. Double-check that the explanations for query string handling and inline type imports (e.g., 'prefer-inline') exactly match the implemented behavior. - Reason this comment was not posted:
Confidence changes required:33%<= threshold50%None
9. docs/rules/no-named-as-default-member.md:1
- Draft comment:
The documentation clearly explains the behavior and provides useful examples regarding use of default exports as object properties. Looks good. - Reason this comment was not posted:
Confidence changes required:0%<= threshold50%None
10. docs/rules/no-named-as-default.md:1
- Draft comment:
The documentation clearly outlines when using an exported name as the local default is a mistake, with examples. No changes needed. - Reason this comment was not posted:
Confidence changes required:0%<= threshold50%None
11. docs/rules/no-rename-default.md:1
- Draft comment:
The example clearly demonstrates the rule’s intent. Ensure that the warning messages used during linting exactly reflect those shown in the documentation. - Reason this comment was not posted:
Confidence changes required:33%<= threshold50%None
12. docs/rules/no-unresolved.md:3
- Draft comment:
The detailed configuration options (including ignore, caseSensitive, and caseSensitiveStrict) are well explained. Verify that these docs match the actual behavior on various filesystems. - Reason this comment was not posted:
Confidence changes required:33%<= threshold50%None
13. package.json:18
- Draft comment:
The exports field now uses a glob ('./': './lib/.js') to expose additional paths. Confirm that the build output includes the flat configs as intended so that ESLint’s extends (e.g. 'import-x/flat/recommended') resolve correctly. - Reason this comment was not posted:
Confidence changes required:33%<= threshold50%None
14. README.md:142
- Draft comment:
Typo: Consider using "available configurations" instead of "available configuration" since it introduces a list. - Reason this comment was not posted:
Comment was on unchanged code.
Workflow ID: wflow_7rpNzYTbTJH4EYJG
You can customize
|
@coderabbitai full review |
Coverage summary from CodacySee diff coverage on Codacy
Coverage variation details
Coverage variation is the difference between the coverage for the head and common ancestor commits of the pull request branch: Diff coverage details
Diff coverage is the percentage of lines that are covered by tests out of the coverable lines that the pull request added or modified: See your quality gate settings Change summary preferences |
✅ Actions performedFull review triggered. |
JounQin
changed the title
ESLint doesn't understand what
flatConfigsis, the actual config object isconfigs. So we need to expose the flat configs there in order for ESLint'sextendslogic to work properly.This means
extends: ['import-x/flat/recommended']will now work.Important
Expose flat configurations in
configsobject to support ESLintextendslogic, with documentation updates and configuration emojis.configsobject insrc/index.tsto support ESLintextendslogic.extends: ['import-x/flat/recommended']now works.README.mdto include examples usingdefineConfigwith flat configurations.docs/rules/*.mdto reflect new flat configuration presets..eslint-doc-generatorrc.js.This description was created by
for e5e1de5. You can customize this summary. It will automatically update as commits are pushed.
Summary by CodeRabbit