Repository: un-ts/eslint-plugin-import-x
Pull request #323: docs: add `why` section on the top to clarify
Author: login: JounQin
Labels: name: documentation
description: Improvements or additions to documentation
Created: 2025-05-14T16:01:08Z | Merged: 2025-05-16T02:18:30Z

close #196

cc @43081j, @adrian-gierakowski , @benmccann and @JoshuaKGoldberg

I'm not a native English speaker, so maybe you can help to improve the sentences. ❤️

also cc @SukkaW 

<!-- ELLIPSIS_HIDDEN -->


----

> [!IMPORTANT]
> Added a "Why" section to the README and updated a development dependency for improved tooling.
> 
>   - **Documentation**:
>     - Added a new "Why" section to `README.md` explaining the rationale for forking and key differences from the original plugin.
>     - Updated Table of Contents in `README.md` to include new sections.
>   - **Chores**:
>     - Replaced `@1stg/lint-staged` with `@1stg/nano-staged` in `package.json` and `.nano-staged.js` for improved tooling.
> 
> <sup>This description was created by </sup>[<img alt="Ellipsis" src="https://img.shields.io/badge/Ellipsis-blue?color=175173">](https://www.ellipsis.dev?ref=un-ts%2Feslint-plugin-import-x&utm_source=github&utm_medium=referral)<sup> for 360a34bbfc8988af112fd7cf2e6b2ac2c3cbc4e9. You can [customize](https://app.ellipsis.dev/un-ts/settings/summaries) this summary. It will automatically update as commits are pushed.</sup>

----


<!-- ELLIPSIS_HIDDEN -->

<!-- This is an auto-generated comment: release notes by coderabbit.ai -->
## Summary by CodeRabbit

- **Documentation**
  - Added a new "Why" section to the README with details on the rationale for forking and key differences from the original plugin.
  - Added a "Differences" section outlining technical distinctions and improvements over the original plugin.
  - Updated the Table of Contents and clarified several sections in the README.

- **Chores**
  - Replaced a development dependency with an updated alternative for improved tooling.
  - Updated export configuration to align with the new development dependency.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->

Linked issue #196: docs: add `Why` or `Different with eslint-plugin-import` in readme
Linked issue comments: user: login: SukkaW
created_at: 2024-12-10T09:36:09Z
body: That's nice to have!
author_association: COLLABORATOR
user: login: adrian-gierakowski
created_at: 2025-05-14T10:09:55Z
body: still not clear to my why would I use this over original `eslint-plugin-import`
author_association: NONE
user: login: JounQin
created_at: 2025-05-14T10:30:38Z
body: https://github.com/un-ts/eslint-plugin-import-x/issues/24

And quote from another PR: https://github.com/shlinkio/js-coding-standard/pull/129#issuecomment-2764434829

PR welcome to add such section.
author_association: MEMBER

Diff:
diff --git a/.nano-staged.js b/.nano-staged.js
index d996fafa..958df410 100644
--- a/.nano-staged.js
+++ b/.nano-staged.js
@@ -1 +1 @@
-export { default } from '@1stg/lint-staged/tsc'
+export { default } from '@1stg/nano-staged/tsc'
diff --git a/README.md b/README.md
index a70a34dc..33a47279 100644
--- a/README.md
+++ b/README.md
@@ -14,12 +14,16 @@
 
 This plugin intends to support linting of ES2015+ (ES6+) import/export syntax, and prevent issues with misspelling of file paths and import names. All the goodness that the ES2015+ static module syntax intends to provide, marked up in your editor.
 
+It started as a fork of [`eslint-plugin-import`] using [`get-tsconfig`] to replace [`tsconfig-paths`] and heavy [`typescript`] under the hood, making it faster, through less [heavy dependency on Typescript](https://github.com/import-js/eslint-plugin-import/blob/da5f6ec13160cb288338db0c2a00c34b2d932f0d/src/exportMap/typescript.js#L16), and cleaner dependencies altogether.
+
 [`eslint-plugin-i` is now `eslint-plugin-import-x`](https://github.com/un-ts/eslint-plugin-import-x/issues/24#issuecomment-1991605123)
 
 **IF YOU ARE USING THIS WITH SUBLIME**: see the [bottom section](#sublimelinter-eslint) for important info.
 
 ## TOC <!-- omit in toc -->
 
+- [Why](#why)
+- [Differences](#differences)
 - [Installation](#installation)
 - [Configuration (legacy: `.eslintrc*`)](#configuration-legacy-eslintrc)
   - [TypeScript](#typescript)
@@ -50,6 +54,35 @@ This plugin intends to support linting of ES2015+ (ES6+) import/export syntax, a
 - [Changelog](#changelog)
 - [License](#license)
 
+## Why
+
+Many issues cannot be fixed easily without API changes. For example, see:
+
+- <https://github.com/import-js/eslint-plugin-import/issues/1479>
+- <https://github.com/import-js/eslint-plugin-import/issues/2108>
+- <https://github.com/import-js/eslint-plugin-import/issues/2111>
+
+[`eslint-plugin-import`] refused to accept BREAKING CHANGES for these issues, so we had to fork it.
+
+[`eslint-plugin-import`] now claims in <https://github.com/un-ts/eslint-plugin-import-x/issues/170> that it will accept BREAKING CHANGES. However, still nothing is happening: <https://github.com/import-js/eslint-plugin-import/pull/3091>.
+
+[`eslint-plugin-import`] refuses to support the `exports` feature, and the maintainer even locked the feature request issue <https://github.com/import-js/eslint-plugin-import/issues/1810> to prevent future discussion. In the meantime, `eslint-plugin-import-x` now provides first-party support for the `exports` feature <https://github.com/un-ts/eslint-plugin-import-x/pull/209>, which will become the default in the next major version (v5).
+
+We haven't resolved all the issues yet, but we are working on them, which could happen in the next major version (v5): <https://github.com/un-ts/eslint-plugin-import-x/issues/235>.
+
+## Differences
+
+So what are the differences from `eslint-plugin-import` exactly?
+
+- we target [Node `^18.18.0 || ^20.9.0 || >=21.1.0`](https://github.com/un-ts/eslint-plugin-import-x/blob/8b2d6d3b612eb57fb68c3fddec25b02fc622df7c/package.json#L12) + [ESLint `^8.57.0 || ^9.0.0`](https://github.com/un-ts/eslint-plugin-import-x/blob/8b2d6d3b612eb57fb68c3fddec25b02fc622df7c/package.json#L71), while `eslint-plugin-import` targets [Node `>=4`](https://github.com/import-js/eslint-plugin-import/blob/da5f6ec13160cb288338db0c2a00c34b2d932f0d/package.json#L6) and [ESLint `^2 || ^3 || ^4 || ^5 || ^6 || ^7.2.0 || ^8 || ^9`](https://github.com/import-js/eslint-plugin-import/blob/da5f6ec13160cb288338db0c2a00c34b2d932f0d/package.json#L115C16-L115C64)
+- we don't depend on old and outdated dependencies, so [we have 49 dependencies](https://npmgraph.js.org/?q=eslint-plugin-import-x) compared to [117 dependencies for `eslint-plugin-import`](https://npmgraph.js.org/?q=eslint-plugin-import)
+- `eslint-plugin-import` uses `tsconfig-paths` + `typescript` itself to load `tsconfig`s while we use the single `get-tsconfig` instead, which is much faster and cleaner
+- `eslint-plugin-import` uses [`resolve`] which doesn't support the `exports` field in `package.json` while we build our own rust-based resolver [`unrs-resolver`] instead, which is feature-rich and way more performant.
+- Our [v3 resolver](./resolvers/README.md#v3) interface shares a single `resolver` instance by default which is used all across resolving chains so it would benefit from caching and memoization out-of-the-box
+- ...
+
+The list could be longer in the future, but we don't want to make it too long here. Hope you enjoy and let's get started.
+
 ## Installation
 
 ```sh
@@ -662,9 +695,15 @@ Detailed changes for each release are documented in [CHANGELOG.md](./CHANGELOG.m
 [MIT][] © [JounQin][]@[1stG.me][]
 
 [`@typescript-eslint/parser`]: https://github.com/typescript-eslint/typescript-eslint/tree/HEAD/packages/parser
+[`eslint-plugin-import`]: https://github.com/import-js/eslint-plugin-import
 [`eslint-import-resolver-typescript`]: https://github.com/import-js/eslint-import-resolver-typescript
 [`eslint_d`]: https://www.npmjs.com/package/eslint_d
 [`eslint-loader`]: https://www.npmjs.com/package/eslint-loader
+[`get-tsconfig`]: https://github.com/privatenumber/get-tsconfig
+[`napi-rs`]: https://github.com/napi-rs/napi-rs
+[`tsconfig-paths`]: https://github.com/dividab/tsconfig-paths
+[`typescript`]: https://github.com/microsoft/TypeScript
+[`unrs-resolver`]: https://github.com/unrs/unrs-resolver
 [`resolve`]: https://www.npmjs.com/package/resolve
 [`externals`]: https://webpack.github.io/docs/library-and-externals.html
 [1stG.me]: https://www.1stG.me
diff --git a/package.json b/package.json
index 5bf87385..7347befe 100644
--- a/package.json
+++ b/package.json
@@ -85,7 +85,7 @@
   },
   "devDependencies": {
     "@1stg/commitlint-config": "^5.0.6",
-    "@1stg/lint-staged": "^4.0.9",
+    "@1stg/nano-staged": "^0.1.1",
     "@1stg/prettier-config": "^5.1.4",
     "@1stg/remark-preset": "^3.1.1",
     "@1stg/simple-git-hooks": "^2.0.1",
diff --git a/yarn.lock b/yarn.lock
index 46163320..61473b6f 100644
--- a/yarn.lock
+++ b/yarn.lock
@@ -16,31 +16,31 @@ __metadata:
   languageName: node
   linkType: hard
 
-"@1stg/config@npm:^1.0.4, @1stg/config@npm:^1.0.5":
+"@1stg/config@npm:^1.0.5":
   version: 1.0.5
   resolution: "@1stg/config@npm:1.0.5"
   checksum: 10c0/f7e4d638f45ea458fc80763ad26402f4606fd2cf37edb282777ab804b1c8abea866185e8287328754675261dc0bcd741d55a88338844bbf79ddc476dbe9b9503
   languageName: node
   linkType: hard
 
-"@1stg/lint-staged@npm:^4.0.9":
-  version: 4.0.9
-  resolution: "@1stg/lint-staged@npm:4.0.9"
+"@1stg/nano-staged@npm:^0.1.1":
+  version: 0.1.1
+  resolution: "@1stg/nano-staged@npm:0.1.1"
   dependencies:
-    "@1stg/config": "npm:^1.0.4"
-    "@1stg/prettier-config": "npm:^5.0.1"
-    "@1stg/tsconfig": "npm:^3.0.2"
+    "@1stg/config": "npm:^1.0.5"
+    "@1stg/prettier-config": "npm:^5.1.1"
+    "@1stg/tsconfig": "npm:^3.0.3"
     "@pkgr/core": "npm:^0.2.2"
     prettier: "npm:^3.5.3"
   peerDependencies:
-    lint-staged: ">=12.1.0"
-  checksum: 10c0/bc576e1b9e8f0fe260f9b3d00b631baa3e74088c41f03936be7028e549fcc57f0210fc8bdd69e574935653e4315fbc91e3e579776ccd0af95448b7ab15780b87
+    nano-staged: ">=0.8.0"
+  checksum: 10c0/3e0652c36c06e5c14836bf2329eb0da9d8cf6e9bb1a59ef4bc27fb85672eea685936d1b9d997ec56c3673e5458ee8cfaf34a79be701798c29b48b542bb0b0dc0
   languageName: node
   linkType: hard
 
-"@1stg/prettier-config@npm:^5.0.1, @1stg/prettier-config@npm:^5.1.4":
-  version: 5.1.4
-  resolution: "@1stg/prettier-config@npm:5.1.4"
+"@1stg/prettier-config@npm:^5.1.1, @1stg/prettier-config@npm:^5.1.4":
+  version: 5.2.0
+  resolution: "@1stg/prettier-config@npm:5.2.0"
   dependencies:
     "@1stg/config": "npm:^1.0.5"
     "@prettier/plugin-pug": "npm:^3.3.0"
@@ -57,7 +57,7 @@ __metadata:
     prettier-plugin-toml: "npm:^2.0.4"
   peerDependencies:
     prettier: ^3.0.0
-  checksum: 10c0/7950dca3881be0604eff57191b34a0f7efc0377b756225ba7ec969c81ef5cf5db2183d574679c4a1d9224e5597e110d5e78f476aab768e15d434b1c5509bbc3b
+  checksum: 10c0/a9879a9a0a84aac41d6896009f109ca03f2544e836bc388df3c581a45c4b47e2369b2104eaf35f3bff9d22fef6f2c6bb0f9941f1381b89f5ad0388e805cec028
   languageName: node
   linkType: hard
 
@@ -94,7 +94,7 @@ __metadata:
   languageName: node
   linkType: hard
 
-"@1stg/tsconfig@npm:^3.0.2, @1stg/tsconfig@npm:^3.0.3":
+"@1stg/tsconfig@npm:^3.0.3":
   version: 3.0.3
   resolution: "@1stg/tsconfig@npm:3.0.3"
   peerDependencies:
@@ -6346,7 +6346,7 @@ __metadata:
   resolution: "eslint-plugin-import-x@workspace:."
   dependencies:
     "@1stg/commitlint-config": "npm:^5.0.6"
-    "@1stg/lint-staged": "npm:^4.0.9"
+    "@1stg/nano-staged": "npm:^0.1.1"
     "@1stg/prettier-config": "npm:^5.1.4"
     "@1stg/remark-preset": "npm:^3.1.1"
     "@1stg/simple-git-hooks": "npm:^2.0.1"


Reviews:
user: login: petercat-assistant[bot]
state: COMMENTED
author_association: NONE
submitted_at: 2025-05-14T16:01:42Z
user: login: ellipsis-dev[bot]
body: > [!IMPORTANT]
> **Looks good to me!  :+1:**
> <details>
> <summary>Reviewed everything up to 32a6b98d562759f0faa9220d77f0d09add5d5d61 in <ellipsistime>2 minutes and 9 seconds</ellipsistime>. Click for details.</summary> 
> 
> - Reviewed `92` lines of code in `3` files
> - Skipped `1` files when reviewing.
> - Skipped posting `6` draft comments. View those below.
> - Modify your [settings](https://app.ellipsis.dev/un-ts/settings/code-review) and [rules](https://app.ellipsis.dev/un-ts/code-review/rules) to customize what types of comments Ellipsis leaves. And don't forget to react with :+1: or :-1: to teach Ellipsis.
> 
> <details>
> <summary>1. <code>.nano-staged.js:1</code></summary>
> 
> - **Draft comment:** 
> Correctly updated export from '@1stg/lint-staged/tsc' to '@1stg/nano-staged/tsc'. Ensure all tooling and docs refer to the new package.
> - **Reason this comment was not posted:**
> Confidence changes required: `0%` <= threshold `50%` None
> 
> 
> </details>
> 
> <details>
> <summary>2. <code>README.md:56</code></summary>
> 
> - **Draft comment:** 
> Consider revising some phrasing in the new 'Why' section (e.g., use 'cannot' instead of 'can not' and 'what are the differences' instead of 'what's the differences') for clarity.
> - **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% While the grammar suggestions are technically correct, they are very minor style changes that don't impact understanding. The text is still perfectly clear as written. PR comments should focus on more substantive issues. Additionally, this is documentation text, not code logic. The grammar issues could make the documentation look less professional. Some readers may notice these small errors. The benefit of fixing these minor grammar issues is outweighed by the noise of having a PR comment about them. The text is understandable as-is. Delete this comment as it focuses on minor style issues rather than substantive changes that would meaningfully improve the code or documentation.
> 
> 
> </details>
> 
> <details>
> <summary>3. <code>package.json:87</code></summary>
> 
> - **Draft comment:** 
> Updated devDependency from '@1stg/lint-staged' to '@1stg/nano-staged'. Confirm that all related scripts and hooks are aligned with this change.
> - **Reason this comment was not posted:**
> Confidence changes required: `0%` <= threshold `50%` None
> 
> 
> </details>
> 
> <details>
> <summary>4. <code>README.md:17</code></summary>
> 
> - **Draft comment:** 
> Typographical note: Consider using the consistent and official casing "TypeScript" instead of "Typescript" in the phrase "dependency on Typescript".
> - **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% While the comment is technically correct about the official casing being "TypeScript", this is a very minor typographical issue in documentation. The meaning is completely clear either way. The rules say not to make comments that are obvious or unimportant. Casing in documentation is not a critical issue that requires a code change. The official branding of TypeScript could be considered important for consistency and professionalism in documentation. Some projects do care about getting branding exactly right. While branding consistency is nice to have, this is too minor of an issue to warrant a PR comment. It doesn't affect functionality and the meaning is clear either way. Delete this comment as it points out a very minor typographical issue that doesn't meaningfully impact the documentation's clarity or accuracy.
> 
> 
> </details>
> 
> <details>
> <summary>5. <code>README.md:58</code></summary>
> 
> - **Draft comment:** 
> Typo: Consider changing "can not" to "cannot" for a more standard usage.
> - **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% While this is technically a valid grammar suggestion, it's an extremely minor stylistic change that doesn't impact code quality or functionality. Both "can not" and "cannot" are grammatically acceptable, though "cannot" is more common. The rules state not to make comments that are obvious or unimportant, and this seems to fall into that category. The change would make the text slightly more polished and professional. Some style guides do explicitly recommend "cannot" over "can not". While technically correct, this kind of minor prose style suggestion in documentation doesn't warrant a PR comment. It doesn't meaningfully improve the codebase. This comment should be deleted as it suggests an unimportant stylistic change that doesn't meaningfully improve the documentation.
> 
> 
> </details>
> 
> <details>
> <summary>6. <code>README.md:71</code></summary>
> 
> - **Draft comment:** 
> Grammar issue: "So what's the differences" should be rephrased to "So what are the differences" or "So what's different".
> - **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 comment is about a real grammatical error in the text. However, the rules state to not make purely informative comments and to only comment if there is clearly a code change required. While this is a valid grammar correction, it's a minor documentation issue that doesn't affect functionality. The rules emphasize focusing on logic issues rather than pure text/documentation changes. The grammar error could make the documentation less professional and harder to understand for non-native English speakers. Documentation quality is important for open source projects. While documentation quality matters, this is a minor grammatical issue that doesn't significantly impact understanding. The rules explicitly state to focus on code logic issues and not make purely informative comments. The comment should be deleted as it violates the rule about not making purely informative comments. The grammatical error is minor and doesn't warrant a PR comment.
> 
> 
> </details>
> 
> 
> Workflow ID: <workflowid>`wflow_25EMChWJpcftjLPe`</workflowid>
> </details>
> 
> <sup>You can customize </sup>[<img alt="Ellipsis" src="https://img.shields.io/badge/Ellipsis-blue?color=175173">](https://www.ellipsis.dev?ref=un-ts%2Feslint-plugin-import-x&utm_source=github&utm_medium=referral)<sup> by changing your [verbosity settings](https://app.ellipsis.dev/un-ts/settings/code-review), reacting with :+1: or :-1:, [replying to comments](https://docs.ellipsis.dev/features/code-review#teaching-ellipsis), or adding [code review rules](https://app.ellipsis.dev/un-ts/code-review/rules).</sup>
state: COMMENTED
author_association: NONE
submitted_at: 2025-05-14T16:03:21Z
user: login: coderabbitai[bot]
body: **Actionable comments posted: 0**

<details>
<summary>🧹 Nitpick comments (3)</summary><blockquote>

<details>
<summary>README.md (3)</summary><blockquote>

`17-18`: **Clarify project introduction phrasing**

The sentence “It starts as a fork of [`eslint-plugin-import`] using [`get-tsconfig`] to replace …” is informal and passive. Consider rephrasing for clarity and directness, for example:

```diff
- It starts as a fork of [`eslint-plugin-import`] using [`get-tsconfig`] …
+ This project forks [`eslint-plugin-import`] and replaces [`tsconfig-paths`] and heavy [`typescript`] with [`get-tsconfig`] to streamline dependencies.
```

---

`56-63`: **Improve wording and grammar in Why section**

- Replace “a lot of issues can not be fixed easily without API changes” with a more concise alternative, e.g.:
  ```diff
  - Because a lot of issues can not be fixed easily without API changes, see
  + Many issues cannot be resolved without API changes; see
  ```
- Use “cannot” instead of “can not” for consistency.

<details>
<summary>🧰 Tools</summary>

<details>
<summary>🪛 LanguageTool</summary>

[style] ~58-~58: Consider using a synonym to be more concise.
Context: ... - [License](#license)  ## Why  Because a lot of issues can not be fixed easily without ...

(A_LOT_OF)

---

[style] ~58-~58: Unless you want to emphasize “not”, use “cannot” which is more common.
Context: ...cense)  ## Why  Because a lot of issues can not be fixed easily without API changes, se...

(CAN_NOT_PREMIUM)

---

[style] ~58-~58: Consider using a different verb for a more formal wording.
Context: ...Why  Because a lot of issues can not be fixed easily without API changes, see  - <htt...

(FIX_RESOLVE)

</details>

</details>

---

`64-69`: **Use consistent casing and concise phrasing for “breaking changes”**

- Avoid ALL CAPS for “BREAKING CHANGES”—consider “Breaking changes” instead.
- Rephrase for brevity:
  ```diff
  - And then it claimed to be allowed to update with BREAKING CHANGES at …, but it still doesn't happen or even seems to happen.
  + Although support for Breaking changes was promised in issue #170, it still hasn’t materialized.
  ```

</blockquote></details>

</blockquote></details>

<details>
<summary>📜 Review details</summary>

**Configuration used: CodeRabbit UI**
**Review profile: CHILL**
**Plan: Pro**

<details>
<summary>📥 Commits</summary>

Reviewing files that changed from the base of the PR and between 8b2d6d3b612eb57fb68c3fddec25b02fc622df7c and 32a6b98d562759f0faa9220d77f0d09add5d5d61.

</details>

<details>
<summary>⛔ Files ignored due to path filters (1)</summary>

* `yarn.lock` is excluded by `!**/yarn.lock`, `!**/*.lock`

</details>

<details>
<summary>📒 Files selected for processing (3)</summary>

* `.nano-staged.js` (1 hunks)
* `README.md` (3 hunks)
* `package.json` (1 hunks)

</details>

<details>
<summary>🧰 Additional context used</summary>

<details>
<summary>🪛 LanguageTool</summary>

<details>
<summary>README.md</summary>

[style] ~58-~58: Consider using a synonym to be more concise.
Context: ... - [License](#license)  ## Why  Because a lot of issues can not be fixed easily without ...

(A_LOT_OF)

---

[style] ~58-~58: Unless you want to emphasize “not”, use “cannot” which is more common.
Context: ...cense)  ## Why  Because a lot of issues can not be fixed easily without API changes, se...

(CAN_NOT_PREMIUM)

---

[style] ~58-~58: Consider using a different verb for a more formal wording.
Context: ...Why  Because a lot of issues can not be fixed easily without API changes, see  - <htt...

(FIX_RESOLVE)

---

[style] ~77-~77: ‘all across’ might be wordy. Consider a shorter alternative.
Context: ...ingle `resolver` instance which is used all across resolving chains so it would benefit fr...

(EN_WORDINESS_PREMIUM_ALL_ACROSS)

</details>

</details>

</details>

<details>
<summary>⏰ Context from checks skipped due to timeout of 90000ms (19)</summary>

* GitHub Check: Codacy Static Code Analysis
* GitHub Check: Lint and Test with Node.js 20 and ESLint 8.56 on windows-latest
* GitHub Check: Lint and Test with Node.js 20 and ESLint 8 on windows-latest
* GitHub Check: autofix
* GitHub Check: Lint and Test with Node.js 20 and ESLint 8 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 18 and ESLint 9 on ubuntu-latest
* GitHub Check: Lint and Test with Node.js 18 and ESLint 9 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 22 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 22 and ESLint 8.56 on windows-latest
* GitHub Check: Lint and Test with Node.js 22 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 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 20 and ESLint 8.56 on windows-latest
* GitHub Check: Lint and Test with Node.js 20 and ESLint 8 on macos-latest

</details>

<details>
<summary>🔇 Additional comments (3)</summary><blockquote>

<details>
<summary>README.md (1)</summary>

`25-25`: **TOC updated with Why section**

The new “Why” entry in the Table of Contents correctly reflects the added section. Nice catch updating the TOC.

</details>
<details>
<summary>package.json (1)</summary>

`88-88`: <details>
<summary>✅ Verification successful</summary>

**Verify complete replacement of lint-staged tooling**

Ensure `@1stg/lint-staged` has been removed from all references (scripts, configs) and that nothing still points to it. You can run:

---

🏁 Script executed:

```shell
#!/bin/bash
# Verify removal of lint-staged references
rg --ignore-case '@1stg/lint-staged' || echo "No @1stg/lint-staged references found."
```

Length of output: 123

---



</details>

**@1stg/lint-staged references fully removed**

A global search (`rg --ignore-case '@1stg/lint-staged'`) returned no matches, confirming that all references to the old lint-staged tooling have been removed.

</details>
<details>
<summary>.nano-staged.js (1)</summary>

`1-1`: **Correctly re-exporting nano-staged**

The file cleanly re-exports the default from `@1stg/nano-staged/tsc`, aligning with the updated devDependency. Looks good.

</details>

</blockquote></details>

</details>

<!-- This is an auto-generated comment by CodeRabbit for review status -->
state: COMMENTED
author_association: CONTRIBUTOR
submitted_at: 2025-05-14T16:03:55Z
user: login: ellipsis-dev[bot]
body: > [!IMPORTANT]
> **Looks good to me!  :+1:**
> <details>
> <summary>Reviewed 35a00870ff33630497b63b8e653153f577de523a in <ellipsistime>1 minute and 59 seconds</ellipsistime>. Click for details.</summary> 
> 
> - Reviewed `96` lines of code in `3` files
> - Skipped `1` files when reviewing.
> - Skipped posting `7` draft comments. View those below.
> - Modify your [settings](https://app.ellipsis.dev/un-ts/settings/code-review) and [rules](https://app.ellipsis.dev/un-ts/code-review/rules) to customize what types of comments Ellipsis leaves. And don't forget to react with :+1: or :-1: to teach Ellipsis.
> 
> <details>
> <summary>1. <code>.nano-staged.js:1</code></summary>
> 
> - **Draft comment:** 
> Verify the update from '@1stg/lint-staged/tsc' to '@1stg/nano-staged/tsc' is intentional and the new package is correctly integrated.
> - **Reason this comment was not posted:**
> Confidence changes required: `0%` <= threshold `50%` None
> 
> 
> </details>
> 
> <details>
> <summary>2. <code>README.md:57</code></summary>
> 
> - **Draft comment:** 
> The new 'Why' and 'Differences' sections add valuable context. Consider minor rephrasing for clarity (e.g. 'cannot' instead of 'can not' and 'What are the differences' instead of 'So what's the differences').
> - **Reason this comment was not posted:**
> Confidence changes required: `50%` <= threshold `50%` None
> 
> 
> </details>
> 
> <details>
> <summary>3. <code>package.json:85</code></summary>
> 
> - **Draft comment:** 
> Updated devDependency from '@1stg/lint-staged' to '@1stg/nano-staged'. Please confirm the new version (^0.1.1) is compatible with the project requirements.
> - **Reason this comment was not posted:**
> Confidence changes required: `33%` <= threshold `50%` None
> 
> 
> </details>
> 
> <details>
> <summary>4. <code>README.md:17</code></summary>
> 
> - **Draft comment:** 
> There is a capitalization inconsistency with 'typescript'. The code snippet uses ``typescript`` in lowercase, but later in the sentence it appears as 'Typescript'. Consider using 'TypeScript' consistently throughout the file to match the official branding.
> - **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 the comment is technically correct that TypeScript's official branding uses that capitalization, this seems like a minor stylistic issue. The meaning is clear regardless of capitalization. The comment doesn't point out a real code issue or bug. It's more of a nitpick about documentation style. The official TypeScript branding could be considered important for a professional open source project. Consistency in documentation can reflect attention to detail. While branding consistency is nice to have, this kind of minor documentation nitpick creates noise and doesn't meaningfully improve the code quality or functionality. Delete this comment as it's too minor and doesn't identify a significant issue that needs fixing.
> 
> 
> </details>
> 
> <details>
> <summary>5. <code>README.md:59</code></summary>
> 
> - **Draft comment:** 
> Typographical suggestion: Consider replacing "can not" with "cannot" for a more standard form.
> - **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% The rules state to NOT make comments that are obvious or unimportant. This is a very minor stylistic suggestion about documentation that doesn't impact functionality. While technically correct that "cannot" is more standard, this level of nitpicking about documentation wording is not valuable enough to warrant a comment. The suggestion is technically correct from a formal writing perspective. Documentation quality and consistency does matter for open source projects. While documentation quality matters, this extremely minor stylistic suggestion doesn't rise to the level of importance that would justify asking the author to make a change. Both forms are widely understood. Delete this comment as it is too minor and unimportant to warrant asking for a change.
> 
> 
> </details>
> 
> <details>
> <summary>6. <code>README.md:74</code></summary>
> 
> - **Draft comment:** 
> Typographical note: The phrase "what's the differences" sounds off. You might want to change it to "what are the differences" or "what's the difference" based on your intended meaning.
> - **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% While the comment points out a real grammatical issue, it's a very minor one that doesn't affect code functionality or documentation clarity. The rules state not to make purely informative comments or comments that are obvious/unimportant. Grammar nitpicks generally fall into this category unless they significantly impact understanding. The grammar error could potentially make the documentation look less professional. Some might argue that maintaining high quality even in small details is important for documentation. While professionalism is important, this is a very minor grammatical issue that doesn't impede understanding. The rules explicitly say not to make unimportant comments or purely informative ones. This comment should be deleted as it's too minor and purely informative, violating the rules about not making unimportant comments.
> 
> 
> </details>
> 
> <details>
> <summary>7. <code>README.md:80</code></summary>
> 
> - **Draft comment:** 
> Minor phrasing note: Consider changing "memoization out of box" to "memoization out of the box" to improve clarity.
> - **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% While the suggestion is technically correct English, it's a very minor documentation wording issue. The meaning is still clear with the current phrasing. The rules state not to make purely informative comments or comments that are obvious/unimportant. Documentation phrasing suggestions like this don't require code changes. The phrase "out of box" could be considered slightly confusing to non-native English speakers. Clear documentation is important. While clear docs are good, this is an extremely minor phrasing issue that doesn't impact understanding. The current phrase is still understandable. Delete this comment as it's a minor documentation phrasing suggestion that doesn't require code changes.
> 
> 
> </details>
> 
> 
> Workflow ID: <workflowid>`wflow_lJEc9SKbldlBGxxX`</workflowid>
> </details>
> 
> <sup>You can customize </sup>[<img alt="Ellipsis" src="https://img.shields.io/badge/Ellipsis-blue?color=175173">](https://www.ellipsis.dev?ref=un-ts%2Feslint-plugin-import-x&utm_source=github&utm_medium=referral)<sup> by changing your [verbosity settings](https://app.ellipsis.dev/un-ts/settings/code-review), reacting with :+1: or :-1:, [replying to comments](https://docs.ellipsis.dev/features/code-review#teaching-ellipsis), or adding [code review rules](https://app.ellipsis.dev/un-ts/code-review/rules).</sup>
state: COMMENTED
author_association: NONE
submitted_at: 2025-05-14T16:33:33Z
user: login: coderabbitai[bot]
body: **Actionable comments posted: 0**

<details>
<summary>🧹 Nitpick comments (6)</summary><blockquote>

<details>
<summary>README.md (6)</summary><blockquote>

`17-17`: **Refine fork rationale for conciseness and clarity**

Current sentence is lengthy and repeats “heavy” twice. Consider rewriting for a more concise narrative. For example:

```diff
- It started as a fork of [`eslint-plugin-import`] using [`get-tsconfig`] to replace [`tsconfig-paths`] and heavy [`typescript`] under the hood, making it faster, through less heavy dependency on Typescript, and cleaner dependencies altogether.
+ It began as a fork of [`eslint-plugin-import`], replacing `tsconfig-paths` and `typescript` with the lightweight [`get-tsconfig`] for faster performance and a cleaner dependency tree.
```

---

`57-64`: **Improve "Why" section wording**

The introduction uses informal phrasing and “can not”. Consider a more formal rewrite:

```diff
- Because a lot of issues can not be fixed easily without API changes, see
+ Many issues cannot be resolved without breaking API changes; see:
   - https://github.com/import-js/eslint-plugin-import/issues/1479
   - https://github.com/import-js/eslint-plugin-import/issues/2108
   - https://github.com/import-js/eslint-plugin-import/issues/2111
```

<details>
<summary>🧰 Tools</summary>

<details>
<summary>🪛 LanguageTool</summary>

[style] ~59-~59: Consider using a synonym to be more concise.
Context: ... - [License](#license)  ## Why  Because a lot of issues can not be fixed easily without ...

(A_LOT_OF)

---

[style] ~59-~59: Unless you want to emphasize “not”, use “cannot” which is more common.
Context: ...cense)  ## Why  Because a lot of issues can not be fixed easily without API changes, se...

(CAN_NOT_PREMIUM)

---

[style] ~59-~59: Consider using a different verb for a more formal wording.
Context: ...Why  Because a lot of issues can not be fixed easily without API changes, see  - <htt...

(FIX_RESOLVE)

</details>

</details>

---

`65-68`: **Clarify rationale for forking due to API change refusal**

The phrasing is a bit informal. For example:

```diff
- But [`eslint-plugin-import`] refused to accept BREAKING CHANGES for these issues, so we have to fork it.
+ However, [`eslint-plugin-import`] declined to accept these breaking API changes, necessitating our fork.
```

And for the subsequent sentence:

```diff
- And then [`eslint-plugin-import`] claimed to be allowed to update with BREAKING CHANGES at <link>, but it still doesn't happen or even seems to happen: <link>.
+ Although [`eslint-plugin-import`] later indicated openness to breaking changes (see <link>), no such updates have materialized.
```

---

`70-70`: **Clarify future work statement**

Rewrite for clarity and active voice:

```diff
- We haven't resolved all the issues yet, but we are working on it which could happen in the next major version (v5): <link>.
+ While not all issues are resolved, we plan to address them in the next major version (v5): <link>.
```

<details>
<summary>🧰 Tools</summary>

<details>
<summary>🪛 LanguageTool</summary>

[uncategorized] ~70-~70: Possible missing comma found.
Context: ...l the issues yet, but we are working on it which could happen in the next major ve...

(AI_HYDRA_LEO_MISSING_COMMA)

</details>

</details>

---

`76-82`: **Standardize bullet capitalization in Differences section**

Bullets currently start with lowercase; for consistency, capitalize the first word of each item:

```diff
- - we target [Node …]
+ - We target [Node …]
- - we don't depend on old and outdated dependencies…
+ - We don't depend on old and outdated dependencies…
- …
```

This aligns style with other sections and improves readability.

<details>
<summary>🧰 Tools</summary>

<details>
<summary>🪛 LanguageTool</summary>

[style] ~80-~80: ‘all across’ might be wordy. Consider a shorter alternative.
Context: ...lver` instance by default which is used all across resolving chains so it would benefit fr...

(EN_WORDINESS_PREMIUM_ALL_ACROSS)

</details>

</details>

---

`697-704`: **Organize and alphabetize new reference definitions**

The new footnote definitions (`[`get-tsconfig`]`, [`tsconfig-paths`], [`typescript`], [`unrs-resolver`], `[napi-rs]`) are appended but out of order. Consider grouping all custom references together and sorting them (e.g., alphabetically or by first use) to simplify maintenance.



Also applies to: 710-710

</blockquote></details>

</blockquote></details>

<details>
<summary>📜 Review details</summary>

**Configuration used: CodeRabbit UI**
**Review profile: CHILL**
**Plan: Pro**

<details>
<summary>📥 Commits</summary>

Reviewing files that changed from the base of the PR and between 32a6b98d562759f0faa9220d77f0d09add5d5d61 and 35a00870ff33630497b63b8e653153f577de523a.

</details>

<details>
<summary>⛔ Files ignored due to path filters (1)</summary>

* `yarn.lock` is excluded by `!**/yarn.lock`, `!**/*.lock`

</details>

<details>
<summary>📒 Files selected for processing (3)</summary>

* `.nano-staged.js` (1 hunks)
* `README.md` (3 hunks)
* `package.json` (1 hunks)

</details>

<details>
<summary>✅ Files skipped from review due to trivial changes (2)</summary>

* package.json
* .nano-staged.js

</details>

<details>
<summary>🧰 Additional context used</summary>

<details>
<summary>🪛 LanguageTool</summary>

<details>
<summary>README.md</summary>

[style] ~59-~59: Consider using a synonym to be more concise.
Context: ... - [License](#license)  ## Why  Because a lot of issues can not be fixed easily without ...

(A_LOT_OF)

---

[style] ~59-~59: Unless you want to emphasize “not”, use “cannot” which is more common.
Context: ...cense)  ## Why  Because a lot of issues can not be fixed easily without API changes, se...

(CAN_NOT_PREMIUM)

---

[style] ~59-~59: Consider using a different verb for a more formal wording.
Context: ...Why  Because a lot of issues can not be fixed easily without API changes, see  - <htt...

(FIX_RESOLVE)

---

[uncategorized] ~70-~70: Possible missing comma found.
Context: ...l the issues yet, but we are working on it which could happen in the next major ve...

(AI_HYDRA_LEO_MISSING_COMMA)

---

[style] ~80-~80: ‘all across’ might be wordy. Consider a shorter alternative.
Context: ...lver` instance by default which is used all across resolving chains so it would benefit fr...

(EN_WORDINESS_PREMIUM_ALL_ACROSS)

</details>

</details>

</details>

<details>
<summary>⏰ Context from checks skipped due to timeout of 90000ms (21)</summary>

* GitHub Check: Codacy Static Code Analysis
* GitHub Check: Lint and Test with Node.js 22 and ESLint 8.56 on ubuntu-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 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 20 and ESLint 8 on windows-latest
* GitHub Check: Lint and Test with Node.js 22 and ESLint 9 on macos-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 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 20 and ESLint 8.56 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 20 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 22 and ESLint 8.56 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 8.56 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 9 on macos-latest
* GitHub Check: Lint and Test with Node.js 18 and ESLint 9 on macos-latest

</details>

<details>
<summary>🔇 Additional comments (1)</summary><blockquote>

<details>
<summary>README.md (1)</summary>

`25-26`: **TOC updated with new sections**

The manual Table of Contents now includes links to the new “Why” and “Differences” sections, matching the added headings below.

</details>

</blockquote></details>

</details>

<!-- This is an auto-generated comment by CodeRabbit for review status -->
state: COMMENTED
author_association: CONTRIBUTOR
submitted_at: 2025-05-14T16:34:29Z
user: login: benmccann
state: COMMENTED
author_association: CONTRIBUTOR
submitted_at: 2025-05-14T23:52:34Z
user: login: JounQin
state: COMMENTED
author_association: MEMBER
submitted_at: 2025-05-15T00:12:40Z
user: login: ellipsis-dev[bot]
body: > [!IMPORTANT]
> **Looks good to me!  :+1:**
> <details>
> <summary>Reviewed 0d2833ac98f380de138b7ac9d687201e07a1e43f in <ellipsistime>1 minute and 53 seconds</ellipsistime>. Click for details.</summary> 
> 
> - Reviewed `13` lines of code in `1` files
> - Skipped `0` files when reviewing.
> - Skipped posting `2` draft comments. View those below.
> - Modify your [settings](https://app.ellipsis.dev/un-ts/settings/code-review) and [rules](https://app.ellipsis.dev/un-ts/code-review/rules) to customize what types of comments Ellipsis leaves. And don't forget to react with :+1: or :-1: to teach Ellipsis.
> 
> <details>
> <summary>1. <code>README.md:17</code></summary>
> 
> - **Draft comment:** 
> Consider rephrasing for clarity and consistency. For example, you could write: "It started as a fork of [`eslint-plugin-import`] that uses [`get-tsconfig`] to replace [`tsconfig-paths`] and reduce its heavy dependency on TypeScript, thereby improving speed and streamlining dependencies." This also ensures consistent capitalization of 'TypeScript'.
> - **Reason this comment was not posted:**
> Comment was on unchanged code.
> 
> 
> </details>
> 
> <details>
> <summary>2. <code>README.md:17</code></summary>
> 
> - **Draft comment:** 
> It looks like "typescript" is referenced in two different ways in this line – once as `typescript` (in code style) and once in the link text as "Typescript". Consider using the official and consistent spelling "TypeScript" in both places.
> - **Reason this comment was not posted:**
> Comment was on unchanged code.
> 
> 
> </details>
> 
> 
> Workflow ID: <workflowid>`wflow_lDSE4QJ3iBYUApK1`</workflowid>
> </details>
> 
> <sup>You can customize </sup>[<img alt="Ellipsis" src="https://img.shields.io/badge/Ellipsis-blue?color=175173">](https://www.ellipsis.dev?ref=un-ts%2Feslint-plugin-import-x&utm_source=github&utm_medium=referral)<sup> by changing your [verbosity settings](https://app.ellipsis.dev/un-ts/settings/code-review), reacting with :+1: or :-1:, [replying to comments](https://docs.ellipsis.dev/features/code-review#teaching-ellipsis), or adding [code review rules](https://app.ellipsis.dev/un-ts/code-review/rules).</sup>
state: COMMENTED
author_association: NONE
submitted_at: 2025-05-15T00:18:39Z
user: login: coderabbitai[bot]
body: **Actionable comments posted: 0**

<details>
<summary>🧹 Nitpick comments (3)</summary><blockquote>

<details>
<summary>README.md (3)</summary><blockquote>

`17-18`: **Refine introductory sentence for clarity and conciseness**

The new sentence is quite long and a bit wordy. Consider a more direct phrasing to improve readability.  


```diff
-It started as a fork of [`eslint-plugin-import`] using [`get-tsconfig`] to replace [`tsconfig-paths`] and heavy [`typescript`] under the hood, making it faster, through less [heavy dependency on Typescript](https://github.com/import-js/eslint-plugin-import/blob/da5f6ec13160cb288338db0c2a00c34b2d932f0d/src/exportMap/typescript.js#L16), and cleaner dependencies altogether.
+It began as a fork of [`eslint-plugin-import`] to replace `tsconfig-paths` and `typescript` with `get-tsconfig`, reducing dependency weight and improving performance.
```

---

`59-64`: **Improve grammar and style in the introductory paragraph**

To sound more formal and concise, replace “a lot of” with “many” and use “cannot” as one word. Also, rephrase for clarity:

```diff
-Because a lot of issues can not be fixed easily without API changes, see
+Many issues cannot be resolved without API changes. See:
```

<details>
<summary>🧰 Tools</summary>

<details>
<summary>🪛 LanguageTool</summary>

[style] ~59-~59: Consider using a synonym to be more concise.
Context: ... - [License](#license)  ## Why  Because a lot of issues can not be fixed easily without ...

(A_LOT_OF)

---

[style] ~59-~59: Unless you want to emphasize “not”, use “cannot” which is more common.
Context: ...cense)  ## Why  Because a lot of issues can not be fixed easily without API changes, se...

(CAN_NOT_PREMIUM)

---

[style] ~59-~59: Consider using a different verb for a more formal wording.
Context: ...Why  Because a lot of issues can not be fixed easily without API changes, see  - <htt...

(FIX_RESOLVE)

</details>

</details>

---

`65-71`: **Enhance flow by removing leading conjunctions**

Avoid starting sentences with “But” or “And then” for a cleaner narrative. For example:

```diff
-But [`eslint-plugin-import`] refused to accept BREAKING CHANGES for these issues, so we have to fork it.
+However, [`eslint-plugin-import`] declined these breaking changes, necessitating our fork.

-And then [`eslint-plugin-import`] claimed to be allowed to update with BREAKING CHANGES at <https://github.com/un-ts/eslint-plugin-import-x/issues/170>, but it still doesn't happen or even seems to happen: <https://github.com/import-js/eslint-plugin-import/pull/3091>.
+Later, [`eslint-plugin-import`] indicated a willingness to introduce breaking changes (see https://github.com/un-ts/eslint-plugin-import-x/issues/170), but no progress has been made (https://github.com/import-js/eslint-plugin-import/pull/3091).
```
This also tightens the language and improves readability.

</blockquote></details>

</blockquote></details>

<details>
<summary>📜 Review details</summary>

**Configuration used: CodeRabbit UI**
**Review profile: CHILL**
**Plan: Pro**
**Cache: Disabled due to data retention organization setting**
**Knowledge Base: Disabled due to data retention organization setting**


<details>
<summary>📥 Commits</summary>

Reviewing files that changed from the base of the PR and between 35a00870ff33630497b63b8e653153f577de523a and 0d2833ac98f380de138b7ac9d687201e07a1e43f.

</details>

<details>
<summary>📒 Files selected for processing (1)</summary>

* `README.md` (3 hunks)

</details>

<details>
<summary>🧰 Additional context used</summary>

<details>
<summary>🪛 LanguageTool</summary>

<details>
<summary>README.md</summary>

[style] ~59-~59: Consider using a synonym to be more concise.
Context: ... - [License](#license)  ## Why  Because a lot of issues can not be fixed easily without ...

(A_LOT_OF)

---

[style] ~59-~59: Unless you want to emphasize “not”, use “cannot” which is more common.
Context: ...cense)  ## Why  Because a lot of issues can not be fixed easily without API changes, se...

(CAN_NOT_PREMIUM)

---

[style] ~59-~59: Consider using a different verb for a more formal wording.
Context: ...Why  Because a lot of issues can not be fixed easily without API changes, see  - <htt...

(FIX_RESOLVE)

---

[style] ~80-~80: ‘all across’ might be wordy. Consider a shorter alternative.
Context: ...lver` instance by default which is used all across resolving chains so it would benefit fr...

(EN_WORDINESS_PREMIUM_ALL_ACROSS)

</details>

</details>

</details>

<details>
<summary>⏰ Context from checks skipped due to timeout of 90000ms (21)</summary>

* GitHub Check: Codacy Static Code Analysis
* GitHub Check: Lint and Test with Node.js 22 and ESLint 8.56 on windows-latest
* GitHub Check: Lint and Test with Node.js 22 and ESLint 9 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 20 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 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 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 22 and ESLint 8.56 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 18 and ESLint 8.56 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 on ubuntu-latest
* GitHub Check: Lint and Test with Node.js 20 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 22 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 18 and ESLint 8 on macos-latest

</details>

<details>
<summary>🔇 Additional comments (3)</summary><blockquote>

<details>
<summary>README.md (3)</summary>

`25-26`: **TOC updated to include new sections**

The Table of Contents now correctly lists the newly added "Why" and "Differences" sections.

---

`57-58`: **New “Why” section heading inserted appropriately**

The heading introduces the rationale at the top of the README and follows the existing style.

---

`697-697`: **Link references for added dependencies are present and correct**

The reference URLs for `eslint-plugin-import`, `get-tsconfig`, `tsconfig-paths`, `typescript`, and `unrs-resolver` match the labels introduced above. No issues found.  



Also applies to: 701-704

</details>

</blockquote></details>

</details>

<!-- This is an auto-generated comment by CodeRabbit for review status -->
state: COMMENTED
author_association: CONTRIBUTOR
submitted_at: 2025-05-15T00:19:46Z
user: login: benmccann
state: COMMENTED
author_association: CONTRIBUTOR
submitted_at: 2025-05-15T03:12:12Z
user: login: benmccann
state: COMMENTED
author_association: CONTRIBUTOR
submitted_at: 2025-05-15T03:12:41Z
user: login: benmccann
state: COMMENTED
author_association: CONTRIBUTOR
submitted_at: 2025-05-15T03:14:54Z
user: login: benmccann
state: COMMENTED
author_association: CONTRIBUTOR
submitted_at: 2025-05-15T03:16:17Z
user: login: benmccann
state: COMMENTED
author_association: CONTRIBUTOR
submitted_at: 2025-05-15T03:16:37Z
user: login: coderabbitai[bot]
body: **Actionable comments posted: 0**

<details>
<summary>🧹 Nitpick comments (5)</summary><blockquote>

<details>
<summary>README.md (5)</summary><blockquote>

`17-17`: **Consider improving clarity and grammar in the fork rationale**  
This sentence is lengthy and can be split for readability; also correct “heavy dependency on Typescript” to “heavy TypeScript dependency” and simplify phrasing.  
  
Example diff:
```diff
-It started as a fork of [`eslint-plugin-import`] using [`get-tsconfig`] to replace [`tsconfig-paths`] and heavy [`typescript`] under the hood, making it faster, through less [heavy dependency on Typescript](https://github.com/import-js/eslint-plugin-import/blob/da5f6ec13160cb288338db0c2a00c34b2d932f0d/src/exportMap/typescript.js#L16), and cleaner dependencies altogether.
+This project began as a fork of [`eslint-plugin-import`], replacing [`tsconfig-paths`] and the heavy [`typescript`]-based loader with [`get-tsconfig`] to reduce dependency bloat and improve performance.
```

---

`59-63`: **Revise wording for readability and consistency**  
Use “cannot” instead of “can not”, replace “A lot of issues” with “Many issues”, and refine the lead-in to the bullet list. Also consider adding descriptive text for each issue link.  
  
Example:
```diff
-A lot of issues can not be fixed easily without API changes. E.g. see:
+Many issues cannot be resolved without breaking API changes. For example:
```

<details>
<summary>🧰 Tools</summary>

<details>
<summary>🪛 LanguageTool</summary>

[style] ~59-~59: Unless you want to emphasize “not”, use “cannot” which is more common.
Context: ...nse](#license)  ## Why  A lot of issues can not be fixed easily without API changes. E....

(CAN_NOT_PREMIUM)

---

[style] ~59-~59: Consider using a different verb for a more formal wording.
Context: ...se)  ## Why  A lot of issues can not be fixed easily without API changes. E.g. see:  ...

(FIX_RESOLVE)

</details>

</details>

---

`65-65`: **Wrap “breaking changes” in code ticks and lowercase for consistency**  
Standardize styling: use backticks for `breaking changes` and prefer lowercase.  
  
Example:
```diff
-[`eslint-plugin-import`] refused to accept BREAKING CHANGES for these issues, so we had to fork it.
+[`eslint-plugin-import`] refused to accept `breaking changes` for these issues, so we had to fork it.
```

---

`67-67`: **Soften tone and clarify progress statement**  
Replace “claims” with “states” and “still nothing is happening” with “no progress has been made” for neutrality.  
  
Example:
```diff
-[`eslint-plugin-import`] now claims in <https://github.com/un-ts/eslint-plugin-import-x/issues/170> that it will accept BREAKING CHANGES. However, still nothing is happening: <https://github.com/import-js/eslint-plugin-import/pull/3091>.
+[`eslint-plugin-import`] now states in <https://github.com/un-ts/eslint-plugin-import-x/issues/170> that it will accept breaking changes, but no progress has been made: <https://github.com/import-js/eslint-plugin-import/pull/3091>.
```

---

`69-69`: **Clarify the timeline and add comma for grammar**  
Add a comma before “which” and make it clear what will happen in the next major version.  
  
Example:
```diff
-We haven't resolved all the issues yet, but we are working on it which could happen in the next major version (v5): <https://github.com/un-ts/eslint-plugin-import-x/issues/235>.
+We haven’t resolved all issues yet, but we are actively working on them, which we expect to address in the next major version (v5): <https://github.com/un-ts/eslint-plugin-import-x/issues/235>.
```

</blockquote></details>

</blockquote></details>

<details>
<summary>📜 Review details</summary>

**Configuration used: CodeRabbit UI**
**Review profile: CHILL**
**Plan: Pro**
**Cache: Disabled due to data retention organization setting**
**Knowledge Base: Disabled due to data retention organization setting**


<details>
<summary>📥 Commits</summary>

Reviewing files that changed from the base of the PR and between 0d2833ac98f380de138b7ac9d687201e07a1e43f and ae2c47304c1be24bb37c3470179b75e3bab25ebf.

</details>

<details>
<summary>📒 Files selected for processing (1)</summary>

* `README.md` (3 hunks)

</details>

<details>
<summary>🧰 Additional context used</summary>

<details>
<summary>🪛 LanguageTool</summary>

<details>
<summary>README.md</summary>

[style] ~58-~58: Consider using a synonym to be more concise.
Context: ...angelog) - [License](#license)  ## Why  A lot of issues can not be fixed easily without ...

(A_LOT_OF)

---

[style] ~59-~59: Unless you want to emphasize “not”, use “cannot” which is more common.
Context: ...nse](#license)  ## Why  A lot of issues can not be fixed easily without API changes. E....

(CAN_NOT_PREMIUM)

---

[style] ~59-~59: Consider using a different verb for a more formal wording.
Context: ...se)  ## Why  A lot of issues can not be fixed easily without API changes. E.g. see:  ...

(FIX_RESOLVE)

---

[style] ~79-~79: ‘all across’ might be wordy. Consider a shorter alternative.
Context: ...lver` instance by default which is used all across resolving chains so it would benefit fr...

(EN_WORDINESS_PREMIUM_ALL_ACROSS)

</details>

</details>

</details>

<details>
<summary>⏰ Context from checks skipped due to timeout of 90000ms (21)</summary>

* GitHub Check: Codacy Static Code Analysis
* 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 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 9 on windows-latest
* GitHub Check: Lint and Test with Node.js 20 and ESLint 9 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 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 22 and ESLint 9 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 18 and ESLint 9 on ubuntu-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 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 8 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 22 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 18 and ESLint 8 on macos-latest
* GitHub Check: Lint and Test with Node.js 18 and ESLint 8.56 on macos-latest

</details>

<details>
<summary>🔇 Additional comments (2)</summary><blockquote>

<details>
<summary>README.md (2)</summary>

`25-26`: **TOC entries for new sections look correct**  
The added `- [Why](#why)` and `- [Differences](#differences)` align with the new headings.

---

`57-57`: **New “Why” section introduced appropriately**  
The heading clearly marks the rationale section at the top.

</details>

</blockquote></details>

</details>

<!-- This is an auto-generated comment by CodeRabbit for review status -->
state: COMMENTED
author_association: CONTRIBUTOR
submitted_at: 2025-05-15T03:17:11Z
user: login: benmccann
state: COMMENTED
author_association: CONTRIBUTOR
submitted_at: 2025-05-15T03:17:46Z
user: login: coderabbitai[bot]
body: **Actionable comments posted: 1**

<details>
<summary>🧹 Nitpick comments (2)</summary><blockquote>

<details>
<summary>README.md (2)</summary><blockquote>

`17-18`: **Refine the fork rationale sentence for clarity**  
The current sentence is lengthy and mixes multiple points. Consider splitting it and reordering to improve readability.  
Proposed diff:  
```diff
-It started as a fork of [`eslint-plugin-import`] using [`get-tsconfig`] to replace [`tsconfig-paths`] and heavy [`typescript`] under the hood, making it faster, through less [heavy dependency on Typescript], and cleaner dependencies altogether.
+This plugin began as a fork of [`eslint-plugin-import`] to reduce dependency weight and improve speed. It replaces `tsconfig-paths` and the heavy [`typescript`] dependency with [`get-tsconfig`], resulting in a leaner and faster implementation.
```

---

`71-83`: **Improve bullet consistency in “Differences” section**  
- Capitalize the first word of each bullet for parallel structure.  
- Consider rephrasing the question at line 73 to “What are the exact differences from `eslint-plugin-import`?”  
Example:  
```markdown
## Differences

What are the exact differences from `eslint-plugin-import`?

- We target Node `^18.18.0 || ^20.9.0 || >=21.1.0` and ESLint `^8.57.0 || ^9.0.0`, while `eslint-plugin-import` targets Node `>=4` and ESLint `^2 || ... || ^9`.
- We have only 49 dependencies versus 117 in `eslint-plugin-import`.
- We load tsconfig files with the lightweight `get-tsconfig` package instead of `tsconfig-paths` + `typescript`.
- We use `unrs-resolver` (a `napi-rs` project) instead of `resolve` for faster support of the `exports` field.
- Our v3 resolver shares a single instance for built-in caching and memoization.
- ...
```

<details>
<summary>🧰 Tools</summary>

<details>
<summary>🪛 LanguageTool</summary>

[style] ~79-~79: ‘all across’ might be wordy. Consider a shorter alternative.
Context: ...lver` instance by default which is used all across resolving chains so it would benefit fr...

(EN_WORDINESS_PREMIUM_ALL_ACROSS)

</details>

</details>

</blockquote></details>

</blockquote></details>

<details>
<summary>📜 Review details</summary>

**Configuration used: CodeRabbit UI**
**Review profile: CHILL**
**Plan: Pro**
**Cache: Disabled due to data retention organization setting**
**Knowledge Base: Disabled due to data retention organization setting**


<details>
<summary>📥 Commits</summary>

Reviewing files that changed from the base of the PR and between ae2c47304c1be24bb37c3470179b75e3bab25ebf and 2db56e5a66324138ed988ecb76f9bb871fddd127.

</details>

<details>
<summary>📒 Files selected for processing (1)</summary>

* `README.md` (3 hunks)

</details>

<details>
<summary>🧰 Additional context used</summary>

<details>
<summary>🪛 LanguageTool</summary>

<details>
<summary>README.md</summary>

[style] ~58-~58: Consider using a synonym to be more concise.
Context: ...angelog) - [License](#license)  ## Why  A lot of issues can not be fixed easily without ...

(A_LOT_OF)

---

[style] ~59-~59: Unless you want to emphasize “not”, use “cannot” which is more common.
Context: ...nse](#license)  ## Why  A lot of issues can not be fixed easily without API changes. E....

(CAN_NOT_PREMIUM)

---

[style] ~59-~59: Consider using a different verb for a more formal wording.
Context: ...se)  ## Why  A lot of issues can not be fixed easily without API changes. E.g. see:  ...

(FIX_RESOLVE)

---

[uncategorized] ~69-~69: Possible missing comma found.
Context: ...l the issues yet, but we are working on it which could happen in the next major ve...

(AI_HYDRA_LEO_MISSING_COMMA)

---

[style] ~79-~79: ‘all across’ might be wordy. Consider a shorter alternative.
Context: ...lver` instance by default which is used all across resolving chains so it would benefit fr...

(EN_WORDINESS_PREMIUM_ALL_ACROSS)

</details>

</details>
<details>
<summary>🪛 markdownlint-cli2 (0.17.2)</summary>

<details>
<summary>README.md</summary>

709-709: Link and image reference definitions should be needed
Unused link or image reference definition: "napi-rs"

(MD053, link-image-reference-definitions)

</details>

</details>

</details>

<details>
<summary>⏰ Context from checks skipped due to timeout of 90000ms (21)</summary>

* GitHub Check: Codacy Static Code Analysis
* GitHub Check: Lint and Test with Node.js 22 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 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 20 and ESLint 9 on windows-latest
* GitHub Check: Lint and Test with Node.js 20 and ESLint 9 on ubuntu-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 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 18 and ESLint 8.56 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 20 and ESLint 8.56 on windows-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 9 on macos-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 on macos-latest
* GitHub Check: Lint and Test with Node.js 18 and ESLint 8.56 on macos-latest

</details>

<details>
<summary>🔇 Additional comments (2)</summary><blockquote>

<details>
<summary>README.md (2)</summary>

`25-26`: **Include new sections in the Table of Contents**  
The new "Why" and "Differences" sections are correctly added to the TOC.

---

`696-703`: **Link reference definitions appear correct**  
All new link definitions are used in the document. No unused references detected.  



Also applies to: 709-709

</details>

</blockquote></details>

</details>

<!-- This is an auto-generated comment by CodeRabbit for review status -->
state: COMMENTED
author_association: CONTRIBUTOR
submitted_at: 2025-05-15T03:40:49Z
user: login: ellipsis-dev[bot]
body: > [!IMPORTANT]
> **Looks good to me!  :+1:**
> <details>
> <summary>Reviewed 360a34bbfc8988af112fd7cf2e6b2ac2c3cbc4e9 in <ellipsistime>44 seconds</ellipsistime>. Click for details.</summary> 
> 
> - Reviewed `37` lines of code in `1` files
> - Skipped `0` files when reviewing.
> - Skipped posting `4` draft comments. View those below.
> - Modify your [settings](https://app.ellipsis.dev/un-ts/settings/code-review) and [rules](https://app.ellipsis.dev/un-ts/code-review/rules) to customize what types of comments Ellipsis leaves. And don't forget to react with :+1: or :-1: to teach Ellipsis.
> 
> <details>
> <summary>1. <code>README.md:57</code></summary>
> 
> - **Draft comment:** 
> Improved phrasing in the 'Why' section for clarity: replacing 'A lot of issues can not' with 'Many issues cannot' and 'E.g. see:' with 'For example, see:'.
> - **Reason this comment was not posted:**
> Confidence changes required: `0%` <= threshold `50%` None
> 
> 
> </details>
> 
> <details>
> <summary>2. <code>README.md:67</code></summary>
> 
> - **Draft comment:** 
> Good update for subject-verb agreement: 'working on it' changed to 'working on them' to match the plural 'issues'.
> - **Reason this comment was not posted:**
> Confidence changes required: `0%` <= threshold `50%` None
> 
> 
> </details>
> 
> <details>
> <summary>3. <code>README.md:698</code></summary>
> 
> - **Draft comment:** 
> Added the [`napi-rs`] reference link for clarity in the Differences section; ensure it is correctly linked.
> - **Reason this comment was not posted:**
> Confidence changes required: `0%` <= threshold `50%` None
> 
> 
> </details>
> 
> <details>
> <summary>4. <code>README.md:706</code></summary>
> 
> - **Draft comment:** 
> Removed duplicate [`napi-rs`] reference link to avoid redundancy in the dependency links section.
> - **Reason this comment was not posted:**
> Confidence changes required: `0%` <= threshold `50%` None
> 
> 
> </details>
> 
> 
> Workflow ID: <workflowid>`wflow_CQoLQ8gFYP32H8O7`</workflowid>
> </details>
> 
> <sup>You can customize </sup>[<img alt="Ellipsis" src="https://img.shields.io/badge/Ellipsis-blue?color=175173">](https://www.ellipsis.dev?ref=un-ts%2Feslint-plugin-import-x&utm_source=github&utm_medium=referral)<sup> by changing your [verbosity settings](https://app.ellipsis.dev/un-ts/settings/code-review), reacting with :+1: or :-1:, [replying to comments](https://docs.ellipsis.dev/features/code-review#teaching-ellipsis), or adding [code review rules](https://app.ellipsis.dev/un-ts/code-review/rules).</sup>
state: COMMENTED
author_association: NONE
submitted_at: 2025-05-15T03:53:00Z
user: login: coderabbitai[bot]
body: **Actionable comments posted: 0**

<details>
<summary>🧹 Nitpick comments (6)</summary><blockquote>

<details>
<summary>README.md (6)</summary><blockquote>

`17-17`: **Clarify sentence structure and standardize casing**  
The new sentence begins with "It started…", which can be ambiguous. Consider rephrasing to start with the subject ("This plugin") and standardizing "TypeScript". Also simplify the dependency clause for readability.  
  
```diff
-It started as a fork of [`eslint-plugin-import`] using [`get-tsconfig`] to replace [`tsconfig-paths`] and heavy [`typescript`] under the hood, making it faster, through less [heavy dependency on Typescript](https://github.com/import-js/eslint-plugin-import/blob/da5f6ec13160cb288338db0c2a00c34b2d932f0d/src/exportMap/typescript.js#L16), and cleaner dependencies altogether.
+This plugin started as a fork of [`eslint-plugin-import`], replacing [`tsconfig-paths`] and the heavy [`typescript`] dependency with [`get-tsconfig`] under the hood for better performance and cleaner dependencies.
```

---

`57-64`: **Refine the “Why” introduction**  
- Emphasize that the unresolved issues require _breaking_ API changes.  
- Use “resolved” instead of “fixed” for a formal tone.  
  
```diff
-## Why
-
-Many issues cannot be fixed easily without API changes. For example, see:
+## Why
+
+Many issues cannot be resolved without breaking API changes. For example:
```

<details>
<summary>🧰 Tools</summary>

<details>
<summary>🪛 LanguageTool</summary>

[style] ~59-~59: Consider using a different verb for a more formal wording.
Context: ...license)  ## Why  Many issues cannot be fixed easily without API changes. For example...

(FIX_RESOLVE)

</details>

</details>

---

`65-68`: **Streamline the fork rationale**  
Combine and polish the transition to improve flow and reduce wordiness.  
  
```diff
-[`eslint-plugin-import`] refused to accept BREAKING CHANGES for these issues, so we had to fork it.
+[`eslint-plugin-import`] refused to accept the required breaking changes; therefore, we forked the project.

-[`eslint-plugin-import`] now claims in <https://github.com/un-ts/eslint-plugin-import-x/issues/170> that it will accept BREAKING CHANGES. However, still nothing is happening: <https://github.com/import-js/eslint-plugin-import/pull/3091>.
+Although [`eslint-plugin-import`] now claims it will accept breaking changes (<https://github.com/un-ts/eslint-plugin-import-x/issues/170>), no progress has been made: <https://github.com/import-js/eslint-plugin-import/pull/3091>.
```

---

`69-70`: **Improve clarity of the closing statement**  
Split into two sentences and tighten phrasing for readability.  
  
```diff
-We haven't resolved all the issues yet, but we are working on them, which could happen in the next major version (v5): <https://github.com/un-ts/eslint-plugin-import-x/issues/235>.
+We haven’t resolved all issues yet, but we’re actively working on them. Changes may land in the next major version (v5): <https://github.com/un-ts/eslint-plugin-import-x/issues/235>.
```

---

`75-80`: **Standardize bullet style in “Differences”**  
The list mixes lowercase starts, uppercase starts, and inconsistent punctuation. For consistency, begin each bullet with an uppercase letter and end with a period. Optionally, you can rewrite for parallel structure:  
  
```diff
-- we target Node `^18.18.0 || ^20.9.0 || >=21.1.0` + ESLint `^8.57.0 || ^9.0.0`, while `eslint-plugin-import` targets Node `>=4` and ESLint `^2 || ^3 || …`.
+- We target Node `^18.18.0 || ^20.9.0 || >=21.1.0` and ESLint `^8.57.0 || ^9.0.0`, whereas `eslint-plugin-import` supports Node `>=4` and ESLint `^2 || ^3 || ^4 || ^5 || ^6 || ^7.2.0 || ^8 || ^9`.
```  
*(Apply similar normalization to the remaining bullets.)*

<details>
<summary>🧰 Tools</summary>

<details>
<summary>🪛 LanguageTool</summary>

[style] ~79-~79: ‘all across’ might be wordy. Consider a shorter alternative.
Context: ...lver` instance by default which is used all across resolving chains so it would benefit fr...

(EN_WORDINESS_PREMIUM_ALL_ACROSS)

</details>

</details>

---

`79-79`: **Replace “all across” with a concise alternative**  
Avoid wordiness by using “throughout” instead of “all across”:  
  
```diff
-Our [v3 resolver] interface shares a single `resolver` instance by default which is used all across resolving chains so it would benefit from caching and memoization out-of-the-box.
+Our [v3 resolver] interface shares a single `resolver` instance by default throughout resolving chains, benefiting from caching and memoization out of the box.
```

<details>
<summary>🧰 Tools</summary>

<details>
<summary>🪛 LanguageTool</summary>

[style] ~79-~79: ‘all across’ might be wordy. Consider a shorter alternative.
Context: ...lver` instance by default which is used all across resolving chains so it would benefit fr...

(EN_WORDINESS_PREMIUM_ALL_ACROSS)

</details>

</details>

</blockquote></details>

</blockquote></details>

<details>
<summary>📜 Review details</summary>

**Configuration used: CodeRabbit UI**
**Review profile: CHILL**
**Plan: Pro**
**Cache: Disabled due to data retention organization setting**
**Knowledge Base: Disabled due to data retention organization setting**


<details>
<summary>📥 Commits</summary>

Reviewing files that changed from the base of the PR and between 2db56e5a66324138ed988ecb76f9bb871fddd127 and 360a34bbfc8988af112fd7cf2e6b2ac2c3cbc4e9.

</details>

<details>
<summary>📒 Files selected for processing (1)</summary>

* `README.md` (3 hunks)

</details>

<details>
<summary>🧰 Additional context used</summary>

<details>
<summary>🪛 LanguageTool</summary>

<details>
<summary>README.md</summary>

[style] ~59-~59: Consider using a different verb for a more formal wording.
Context: ...license)  ## Why  Many issues cannot be fixed easily without API changes. For example...

(FIX_RESOLVE)

---

[style] ~79-~79: ‘all across’ might be wordy. Consider a shorter alternative.
Context: ...lver` instance by default which is used all across resolving chains so it would benefit fr...

(EN_WORDINESS_PREMIUM_ALL_ACROSS)

</details>

</details>

</details>

<details>
<summary>⏰ Context from checks skipped due to timeout of 90000ms (21)</summary>

* GitHub Check: Lint and Test with Node.js 20 and ESLint 8.56 on ubuntu-latest
* GitHub Check: Codacy Static Code Analysis
* GitHub Check: Lint and Test with Node.js 22 and ESLint 8.56 on windows-latest
* GitHub Check: Lint and Test with Node.js 22 and ESLint 9 on ubuntu-latest
* GitHub Check: Lint and Test with Node.js 22 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 20 and ESLint 8 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 windows-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 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 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 18 and ESLint 9 on ubuntu-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 ubuntu-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 8.56 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 18 and ESLint 9 on macos-latest

</details>

<details>
<summary>🔇 Additional comments (2)</summary><blockquote>

<details>
<summary>README.md (2)</summary>

`25-26`: **Verify Table of Contents entries**  
The newly added entries for "Why" and "Differences" correctly reference `#why` and `#differences` anchors and match the added sections below.

---

`696-696`: **Confirm reference definitions for new labels**  
All new link references (`eslint-plugin-import`, `get-tsconfig`, `napi-rs`, `tsconfig-paths`, `typescript`, `unrs-resolver`) are properly defined at the end of the file.  



Also applies to: 700-704

</details>

</blockquote></details>

</details>

<!-- This is an auto-generated comment by CodeRabbit for review status -->
state: COMMENTED
author_association: CONTRIBUTOR
submitted_at: 2025-05-15T03:55:35Z
user: login: SukkaW
state: COMMENTED
author_association: COLLABORATOR
submitted_at: 2025-05-15T07:47:45Z
user: login: JounQin
state: COMMENTED
author_association: MEMBER
submitted_at: 2025-05-15T07:49:19Z
user: login: SukkaW
state: COMMENTED
author_association: COLLABORATOR
submitted_at: 2025-05-15T07:49:20Z
user: login: SukkaW
state: COMMENTED
author_association: COLLABORATOR
submitted_at: 2025-05-15T07:59:39Z
user: login: coderabbitai[bot]
body: **Actionable comments posted: 0**

<details>
<summary>🧹 Nitpick comments (3)</summary><blockquote>

<details>
<summary>README.md (3)</summary><blockquote>

`17-18`: **Use correct casing and refine phrasing for clarity**  
The sentence mixes casing (“Typescript”) and the phrase “through less heavy dependency” is awkward. Consider rephrasing and using the proper product name `TypeScript`.  


```diff
-It started as a fork of [`eslint-plugin-import`] using [`get-tsconfig`] to replace [`tsconfig-paths`] and heavy [`typescript`] under the hood, making it faster, through less [heavy dependency on Typescript](https://github.com/import-js/eslint-plugin-import/blob/da5f6ec13160cb288338db0c2a00c34b2d932f0d/src/exportMap/typescript.js#L16), and cleaner dependencies altogether.
+It started as a fork of [`eslint-plugin-import`] using [`get-tsconfig`] to replace [`tsconfig-paths`] and heavy [`typescript`] under the hood, making it faster with a lighter dependency on [TypeScript], and resulting in a cleaner dependency graph.
```

---

`57-71`: **Polish the “Why” section for style and consistency**  
A few minor tweaks can improve readability and tone:
- Replace “still nothing is happening” with “no progress has been made.”
- Use “Meanwhile” instead of “In the meantime” for conciseness.
- Normalize casing/formatting of “Breaking Changes” (e.g. sentence-case or title-case consistently).



```diff
## Why

-Many issues cannot be fixed easily without API changes. For example, see:
+Many issues cannot be fixed easily without breaking API changes. For example:

- [`eslint-plugin-import`] refused to accept BREAKING CHANGES for these issues, so we had to fork it.
+[`eslint-plugin-import`] refused to accept breaking changes for these issues, so we forked it.

-[`eslint-plugin-import`] now claims in <https://github.com/un-ts/eslint-plugin-import-x/issues/170> that it will accept BREAKING CHANGES. However, still nothing is happening: <https://github.com/import-js/eslint-plugin-import/pull/3091>.
+[`eslint-plugin-import`] now claims in <https://github.com/un-ts/eslint-plugin-import-x/issues/170> that it will accept breaking changes. However, no progress has been made: <https://github.com/import-js/eslint-plugin-import/pull/3091>.

-[`eslint-plugin-import`] refuses to support the `exports` feature, and the maintainer even locked the feature request issue <https://github.com/import-js/eslint-plugin-import/issues/1810> to prevent future discussion. In the meantime, `eslint-plugin-import-x` now provides first-party support for the `exports` feature <https://github.com/un-ts/eslint-plugin-import-x/pull/209>, which will become the default in the next major version (v5).
+[`eslint-plugin-import`] refuses to support the `exports` feature and even locked the feature request issue <https://github.com/import-js/eslint-plugin-import/issues/1810>. Meanwhile, `eslint-plugin-import-x` provides first-party support for `exports` <https://github.com/un-ts/eslint-plugin-import-x/pull/209>, which will become the default in v5.

-We haven't resolved all the issues yet, but we are working on them, which could happen in the next major version (v5): <https://github.com/un-ts/eslint-plugin-import-x/issues/235>.
+We haven’t resolved all issues yet, but we’re working on them and expect to address them in the next major version (v5): <https://github.com/un-ts/eslint-plugin-import-x/issues/235>.
```

<details>
<summary>🧰 Tools</summary>

<details>
<summary>🪛 LanguageTool</summary>

[style] ~59-~59: Consider using a different verb for a more formal wording.
Context: ...license)  ## Why  Many issues cannot be fixed easily without API changes. For example...

(FIX_RESOLVE)

---

[style] ~69-~69: ‘In the meantime’ might be wordy. Consider a shorter alternative.
Context: ...ues/1810> to prevent future discussion. In the meantime, `eslint-plugin-import-x` now provides ...

(EN_WORDINESS_PREMIUM_IN_THE_MEANTIME)

</details>

</details>

---

`702-706`: **Remove unused link reference**  
The `[napi-rs]` reference is defined but never used in the document. You can remove this line to satisfy markdownlint and keep the link definitions tidy.  


```diff
-[`napi-rs`]: https://github.com/napi-rs/napi-rs
```

<details>
<summary>🧰 Tools</summary>

<details>
<summary>🪛 markdownlint-cli2 (0.17.2)</summary>

703-703: Link and image reference definitions should be needed
Unused link or image reference definition: "`napi-rs`"

(MD053, link-image-reference-definitions)

</details>

</details>

</blockquote></details>

</blockquote></details>

<details>
<summary>📜 Review details</summary>

**Configuration used: CodeRabbit UI**
**Review profile: CHILL**
**Plan: Pro**
**Cache: Disabled due to data retention organization setting**
**Knowledge Base: Disabled due to data retention organization setting**


<details>
<summary>📥 Commits</summary>

Reviewing files that changed from the base of the PR and between 360a34bbfc8988af112fd7cf2e6b2ac2c3cbc4e9 and f74abd60b7a35905ea7ffae4b29e1cb8bb22856e.

</details>

<details>
<summary>📒 Files selected for processing (1)</summary>

* `README.md` (3 hunks)

</details>

<details>
<summary>🧰 Additional context used</summary>

<details>
<summary>🪛 LanguageTool</summary>

<details>
<summary>README.md</summary>

[style] ~59-~59: Consider using a different verb for a more formal wording.
Context: ...license)  ## Why  Many issues cannot be fixed easily without API changes. For example...

(FIX_RESOLVE)

---

[style] ~69-~69: ‘In the meantime’ might be wordy. Consider a shorter alternative.
Context: ...ues/1810> to prevent future discussion. In the meantime, `eslint-plugin-import-x` now provides ...

(EN_WORDINESS_PREMIUM_IN_THE_MEANTIME)

---

[style] ~81-~81: ‘all across’ might be wordy. Consider a shorter alternative.
Context: ...lver` instance by default which is used all across resolving chains so it would benefit fr...

(EN_WORDINESS_PREMIUM_ALL_ACROSS)

---

[uncategorized] ~81-~81: A comma might be missing here.
Context: ...ault which is used all across resolving chains so it would benefit from caching and me...

(AI_EN_LECTOR_MISSING_PUNCTUATION_COMMA)

</details>

</details>
<details>
<summary>🪛 markdownlint-cli2 (0.17.2)</summary>

<details>
<summary>README.md</summary>

703-703: Link and image reference definitions should be needed
Unused link or image reference definition: "`napi-rs`"

(MD053, link-image-reference-definitions)

</details>

</details>

</details>

<details>
<summary>⏰ Context from checks skipped due to timeout of 90000ms (20)</summary>

* GitHub Check: Codacy Static Code Analysis
* GitHub Check: Lint and Test with Node.js 18 and ESLint 8 on windows-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 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 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 20 and ESLint 9 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 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.56 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 on ubuntu-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 18 and ESLint 9 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 20 and ESLint 9 on macos-latest
* GitHub Check: Lint and Test with Node.js 22 and ESLint 8.56 on macos-latest

</details>

<details>
<summary>🔇 Additional comments (1)</summary><blockquote>

<details>
<summary>README.md (1)</summary>

`25-26`: **Add “Why” and “Differences” to the Table of Contents**  
The new TOC entries correctly link to the newly introduced sections and improve navigation.

</details>

</blockquote></details>

</details>

<!-- This is an auto-generated comment by CodeRabbit for review status -->
state: COMMENTED
author_association: CONTRIBUTOR
submitted_at: 2025-05-15T08:22:12Z
user: login: 43081j
state: APPROVED
author_association: COLLABORATOR
submitted_at: 2025-05-15T08:46:43Z
user: login: JoshuaKGoldberg
state: COMMENTED
author_association: CONTRIBUTOR
submitted_at: 2025-05-16T12:05:33Z
user: login: JoshuaKGoldberg
body: Ok! Sorry for the delay. I left some comments all around. In general I think the high-level topics are good to include, but need more specific, tangible data to be _convincing_.

To that end, some of the comments are quick rhetorical questions. Although I personally think I know the answers to them, they're things I think the README.md needs to back up.
state: COMMENTED
author_association: CONTRIBUTOR
submitted_at: 2025-05-20T14:17:28Z
user: login: JounQin
state: COMMENTED
author_association: MEMBER
submitted_at: 2025-05-20T14:36:28Z
user: login: JounQin
state: COMMENTED
author_association: MEMBER
submitted_at: 2025-05-20T14:42:31Z
user: login: JounQin
state: COMMENTED
author_association: MEMBER
submitted_at: 2025-05-20T14:43:43Z
user: login: JounQin
state: COMMENTED
author_association: MEMBER
submitted_at: 2025-05-20T14:48:50Z
user: login: JounQin
state: COMMENTED
author_association: MEMBER
submitted_at: 2025-05-20T14:51:13Z
user: login: JounQin
state: COMMENTED
author_association: MEMBER
submitted_at: 2025-05-20T14:53:23Z
user: login: JounQin
state: COMMENTED
author_association: MEMBER
submitted_at: 2025-05-20T15:03:24Z
user: login: JounQin
state: COMMENTED
author_association: MEMBER
submitted_at: 2025-05-20T15:04:05Z
user: login: MichaelDeBoey
state: COMMENTED
author_association: NONE
submitted_at: 2025-06-01T23:58:08Z
user: login: ljharb
state: COMMENTED
author_association: CONTRIBUTOR
submitted_at: 2025-06-02T04:02:50Z
user: login: JounQin
state: COMMENTED
author_association: MEMBER
submitted_at: 2025-06-02T04:06:25Z
user: login: ljharb
state: COMMENTED
author_association: CONTRIBUTOR
submitted_at: 2025-06-02T04:10:12Z
user: login: JounQin
state: COMMENTED
author_association: MEMBER
submitted_at: 2025-06-02T04:14:46Z
user: login: ljharb
state: COMMENTED
author_association: CONTRIBUTOR
submitted_at: 2025-06-02T04:16:38Z
user: login: JounQin
state: COMMENTED
author_association: MEMBER
submitted_at: 2025-06-02T04:18:09Z
user: login: ljharb
state: COMMENTED
author_association: CONTRIBUTOR
submitted_at: 2025-06-02T04:21:30Z
user: login: JounQin
state: COMMENTED
author_association: MEMBER
submitted_at: 2025-06-02T04:22:31Z

Review comments:
diff_hunk: @@ -1 +1 @@
-export { default } from '@1stg/lint-staged/tsc'
+export { default } from '@1stg/nano-staged/tsc'
path: .nano-staged.js
user: login: petercat-assistant[bot]
body: Ensure that the new dependency `@1stg/nano-staged` is compatible with all existing configurations and scripts that previously relied on `@1stg/lint-staged`. This change might affect the build or linting process if not properly aligned.
created_at: 2025-05-14T16:01:42Z
author_association: NONE
diff_hunk: @@ -14,12 +14,16 @@
 
 This plugin intends to support linting of ES2015+ (ES6+) import/export syntax, and prevent issues with misspelling of file paths and import names. All the goodness that the ES2015+ static module syntax intends to provide, marked up in your editor.
 
+It started as a fork of [`eslint-plugin-import`] using [`get-tsconfig`] to replace [`tsconfig-paths`] and heavy [`typescript`] under the hood, making it faster, through less heavy dependency on Typescript, and cleaner dependencies altogether.
path: README.md
user: login: benmccann
body: I don't understand. `eslint-plugin-import` only has Typescript in devDependencies same as this library: https://github.com/import-js/eslint-plugin-import/blob/da5f6ec13160cb288338db0c2a00c34b2d932f0d/package.json#L111
created_at: 2025-05-14T23:52:34Z
author_association: CONTRIBUTOR
diff_hunk: @@ -14,12 +14,16 @@
 
 This plugin intends to support linting of ES2015+ (ES6+) import/export syntax, and prevent issues with misspelling of file paths and import names. All the goodness that the ES2015+ static module syntax intends to provide, marked up in your editor.
 
+It started as a fork of [`eslint-plugin-import`] using [`get-tsconfig`] to replace [`tsconfig-paths`] and heavy [`typescript`] under the hood, making it faster, through less heavy dependency on Typescript, and cleaner dependencies altogether.
path: README.md
user: login: JounQin
body: @benmccann Nope, https://github.com/import-js/eslint-plugin-import/blob/da5f6ec13160cb288338db0c2a00c34b2d932f0d/src/exportMap/typescript.js#L16, ~~maybe I should add this link as reference to avoid further misunderstandings~~ added.

Actually `typescript` should be declared as an optional peer dependency in `eslint-plugin-import` but it couldn't due to Node 4 compatibility. 😀

Here is a similar PR example: https://github.com/import-js/eslint-plugin-import/pull/2283
created_at: 2025-05-15T00:12:40Z
author_association: MEMBER
diff_hunk: @@ -50,6 +54,34 @@ This plugin intends to support linting of ES2015+ (ES6+) import/export syntax, a
 - [Changelog](#changelog)
 - [License](#license)
 
+## Why
+
+Because a lot of issues can not be fixed easily without API changes, see
+
+- <https://github.com/import-js/eslint-plugin-import/issues/1479>
+- <https://github.com/import-js/eslint-plugin-import/issues/2108>
+- <https://github.com/import-js/eslint-plugin-import/issues/2111>
+
+But [`eslint-plugin-import`] refused to accept BREAKING CHANGES for these issues, so we have to fork it.
+
+And then [`eslint-plugin-import`] claimed to be allowed to update with BREAKING CHANGES at <https://github.com/un-ts/eslint-plugin-import-x/issues/170>,
+but it still doesn't happen or even seems to happen: <https://github.com/import-js/eslint-plugin-import/pull/3091>.
+
+We haven't resolved all the issues yet, but we are working on it which could happen in the next major version (v5): <https://github.com/un-ts/eslint-plugin-import-x/issues/235>.
path: README.md
user: login: benmccann
body: just minor grammar suggestions
```suggestion
A lot of issues can not be fixed easily without API changes. E.g. see:

- <https://github.com/import-js/eslint-plugin-import/issues/1479>
- <https://github.com/import-js/eslint-plugin-import/issues/2108>
- <https://github.com/import-js/eslint-plugin-import/issues/2111>

[`eslint-plugin-import`] refused to accept BREAKING CHANGES for these issues, so we had to fork it.

[`eslint-plugin-import`] now claims in <https://github.com/un-ts/eslint-plugin-import-x/issues/170> that it will accept BREAKING CHANGES. However, still nothing is happening: <https://github.com/import-js/eslint-plugin-import/pull/3091>.

We haven't resolved all the issues yet, but we are working on it which could happen in the next major version (v5): <https://github.com/un-ts/eslint-plugin-import-x/issues/235>.
```
created_at: 2025-05-15T03:12:11Z
author_association: CONTRIBUTOR
diff_hunk: @@ -50,6 +54,34 @@ This plugin intends to support linting of ES2015+ (ES6+) import/export syntax, a
 - [Changelog](#changelog)
 - [License](#license)
 
+## Why
+
+Because a lot of issues can not be fixed easily without API changes, see
+
+- <https://github.com/import-js/eslint-plugin-import/issues/1479>
+- <https://github.com/import-js/eslint-plugin-import/issues/2108>
+- <https://github.com/import-js/eslint-plugin-import/issues/2111>
+
+But [`eslint-plugin-import`] refused to accept BREAKING CHANGES for these issues, so we have to fork it.
+
+And then [`eslint-plugin-import`] claimed to be allowed to update with BREAKING CHANGES at <https://github.com/un-ts/eslint-plugin-import-x/issues/170>,
+but it still doesn't happen or even seems to happen: <https://github.com/import-js/eslint-plugin-import/pull/3091>.
+
+We haven't resolved all the issues yet, but we are working on it which could happen in the next major version (v5): <https://github.com/un-ts/eslint-plugin-import-x/issues/235>.
+
+## Differences
+
+So what's the differences from `eslint-plugin-import` exactly?
path: README.md
user: login: benmccann
body: ```suggestion
So what are the differences from `eslint-plugin-import` exactly?
```
created_at: 2025-05-15T03:12:41Z
author_association: CONTRIBUTOR
diff_hunk: @@ -50,6 +54,34 @@ This plugin intends to support linting of ES2015+ (ES6+) import/export syntax, a
 - [Changelog](#changelog)
 - [License](#license)
 
+## Why
+
+Because a lot of issues can not be fixed easily without API changes, see
+
+- <https://github.com/import-js/eslint-plugin-import/issues/1479>
+- <https://github.com/import-js/eslint-plugin-import/issues/2108>
+- <https://github.com/import-js/eslint-plugin-import/issues/2111>
+
+But [`eslint-plugin-import`] refused to accept BREAKING CHANGES for these issues, so we have to fork it.
+
+And then [`eslint-plugin-import`] claimed to be allowed to update with BREAKING CHANGES at <https://github.com/un-ts/eslint-plugin-import-x/issues/170>,
+but it still doesn't happen or even seems to happen: <https://github.com/import-js/eslint-plugin-import/pull/3091>.
+
+We haven't resolved all the issues yet, but we are working on it which could happen in the next major version (v5): <https://github.com/un-ts/eslint-plugin-import-x/issues/235>.
+
+## Differences
+
+So what's the differences from `eslint-plugin-import` exactly?
+
+- we target [Node `^18.18.0 || ^20.9.0 || >=21.1.0`](https://github.com/un-ts/eslint-plugin-import-x/blob/8b2d6d3b612eb57fb68c3fddec25b02fc622df7c/package.json#L12) + [ESLint `^8.57.0 || ^9.0.0`](https://github.com/un-ts/eslint-plugin-import-x/blob/8b2d6d3b612eb57fb68c3fddec25b02fc622df7c/package.json#L71), while `eslint-plugin-import` targets [Node `>=4`](https://github.com/import-js/eslint-plugin-import/blob/da5f6ec13160cb288338db0c2a00c34b2d932f0d/package.json#L6) and [ESLint `^2 || ^3 || ^4 || ^5 || ^6 || ^7.2.0 || ^8 || ^9`](https://github.com/import-js/eslint-plugin-import/blob/da5f6ec13160cb288338db0c2a00c34b2d932f0d/package.json#L115C16-L115C64)
+- we don't depend on old and outdated dependencies, so we have short dependency depths, see also <https://github.com/un-ts/eslint-plugin-import-x/pull/11>
path: README.md
user: login: benmccann
body: ```suggestion
- we don't depend on old and outdated dependencies, so [we have 49 dependencies](https://npmgraph.js.org/?q=eslint-plugin-import-x) compared to [117 dependencies for `eslint-plugin-import`](https://npmgraph.js.org/?q=eslint-plugin-import)
```
created_at: 2025-05-15T03:14:53Z
author_association: CONTRIBUTOR
diff_hunk: @@ -50,6 +54,34 @@ This plugin intends to support linting of ES2015+ (ES6+) import/export syntax, a
 - [Changelog](#changelog)
 - [License](#license)
 
+## Why
+
+Because a lot of issues can not be fixed easily without API changes, see
+
+- <https://github.com/import-js/eslint-plugin-import/issues/1479>
+- <https://github.com/import-js/eslint-plugin-import/issues/2108>
+- <https://github.com/import-js/eslint-plugin-import/issues/2111>
+
+But [`eslint-plugin-import`] refused to accept BREAKING CHANGES for these issues, so we have to fork it.
+
+And then [`eslint-plugin-import`] claimed to be allowed to update with BREAKING CHANGES at <https://github.com/un-ts/eslint-plugin-import-x/issues/170>,
+but it still doesn't happen or even seems to happen: <https://github.com/import-js/eslint-plugin-import/pull/3091>.
+
+We haven't resolved all the issues yet, but we are working on it which could happen in the next major version (v5): <https://github.com/un-ts/eslint-plugin-import-x/issues/235>.
+
+## Differences
+
+So what's the differences from `eslint-plugin-import` exactly?
+
+- we target [Node `^18.18.0 || ^20.9.0 || >=21.1.0`](https://github.com/un-ts/eslint-plugin-import-x/blob/8b2d6d3b612eb57fb68c3fddec25b02fc622df7c/package.json#L12) + [ESLint `^8.57.0 || ^9.0.0`](https://github.com/un-ts/eslint-plugin-import-x/blob/8b2d6d3b612eb57fb68c3fddec25b02fc622df7c/package.json#L71), while `eslint-plugin-import` targets [Node `>=4`](https://github.com/import-js/eslint-plugin-import/blob/da5f6ec13160cb288338db0c2a00c34b2d932f0d/package.json#L6) and [ESLint `^2 || ^3 || ^4 || ^5 || ^6 || ^7.2.0 || ^8 || ^9`](https://github.com/import-js/eslint-plugin-import/blob/da5f6ec13160cb288338db0c2a00c34b2d932f0d/package.json#L115C16-L115C64)
+- we don't depend on old and outdated dependencies, so we have short dependency depths, see also <https://github.com/un-ts/eslint-plugin-import-x/pull/11>
+- `eslint-plugin-import` uses `tsconfig-paths` + `typescript` itself to load `tsconfig`s while we use the single `get-tsconfig` instead, which is much faster and cleaner
+- `eslint-plugin-import` uses [`resolve`] which doesn't support `exports` field in `package.json` while we use [`unrs-resolver`] instead, which is a [napi-rs] project so it's much faster
path: README.md
user: login: benmccann
body: ```suggestion
- `eslint-plugin-import` uses [`resolve`] which doesn't support the `exports` field in `package.json` while we use [`unrs-resolver`] instead, which does support it and is a [`napi-rs`] project so is also much faster
```
created_at: 2025-05-15T03:16:17Z
author_association: CONTRIBUTOR
diff_hunk: @@ -50,6 +54,34 @@ This plugin intends to support linting of ES2015+ (ES6+) import/export syntax, a
 - [Changelog](#changelog)
 - [License](#license)
 
+## Why
+
+Because a lot of issues can not be fixed easily without API changes, see
+
+- <https://github.com/import-js/eslint-plugin-import/issues/1479>
+- <https://github.com/import-js/eslint-plugin-import/issues/2108>
+- <https://github.com/import-js/eslint-plugin-import/issues/2111>
+
+But [`eslint-plugin-import`] refused to accept BREAKING CHANGES for these issues, so we have to fork it.
+
+And then [`eslint-plugin-import`] claimed to be allowed to update with BREAKING CHANGES at <https://github.com/un-ts/eslint-plugin-import-x/issues/170>,
+but it still doesn't happen or even seems to happen: <https://github.com/import-js/eslint-plugin-import/pull/3091>.
+
+We haven't resolved all the issues yet, but we are working on it which could happen in the next major version (v5): <https://github.com/un-ts/eslint-plugin-import-x/issues/235>.
+
+## Differences
+
+So what's the differences from `eslint-plugin-import` exactly?
+
+- we target [Node `^18.18.0 || ^20.9.0 || >=21.1.0`](https://github.com/un-ts/eslint-plugin-import-x/blob/8b2d6d3b612eb57fb68c3fddec25b02fc622df7c/package.json#L12) + [ESLint `^8.57.0 || ^9.0.0`](https://github.com/un-ts/eslint-plugin-import-x/blob/8b2d6d3b612eb57fb68c3fddec25b02fc622df7c/package.json#L71), while `eslint-plugin-import` targets [Node `>=4`](https://github.com/import-js/eslint-plugin-import/blob/da5f6ec13160cb288338db0c2a00c34b2d932f0d/package.json#L6) and [ESLint `^2 || ^3 || ^4 || ^5 || ^6 || ^7.2.0 || ^8 || ^9`](https://github.com/import-js/eslint-plugin-import/blob/da5f6ec13160cb288338db0c2a00c34b2d932f0d/package.json#L115C16-L115C64)
+- we don't depend on old and outdated dependencies, so we have short dependency depths, see also <https://github.com/un-ts/eslint-plugin-import-x/pull/11>
+- `eslint-plugin-import` uses `tsconfig-paths` + `typescript` itself to load `tsconfig`s while we use the single `get-tsconfig` instead, which is much faster and cleaner
+- `eslint-plugin-import` uses [`resolve`] which doesn't support `exports` field in `package.json` while we use [`unrs-resolver`] instead, which is a [napi-rs] project so it's much faster
+- Our [v3 resolver](./resolvers/README.md#v3) interface shares a single `resolver` instance by default which is used all across resolving chains so it would benefit from caching and memoization out of box
path: README.md
user: login: benmccann
body: ```suggestion
- Our [v3 resolver](./resolvers/README.md#v3) interface shares a single `resolver` instance by default which is used all across resolving chains so it would benefit from caching and memoization out-of-the-box
```
created_at: 2025-05-15T03:16:37Z
author_association: CONTRIBUTOR
diff_hunk: @@ -50,6 +54,34 @@ This plugin intends to support linting of ES2015+ (ES6+) import/export syntax, a
 - [Changelog](#changelog)
 - [License](#license)
 
+## Why
+
+Because a lot of issues can not be fixed easily without API changes, see
+
+- <https://github.com/import-js/eslint-plugin-import/issues/1479>
+- <https://github.com/import-js/eslint-plugin-import/issues/2108>
+- <https://github.com/import-js/eslint-plugin-import/issues/2111>
+
+But [`eslint-plugin-import`] refused to accept BREAKING CHANGES for these issues, so we have to fork it.
+
+And then [`eslint-plugin-import`] claimed to be allowed to update with BREAKING CHANGES at <https://github.com/un-ts/eslint-plugin-import-x/issues/170>,
+but it still doesn't happen or even seems to happen: <https://github.com/import-js/eslint-plugin-import/pull/3091>.
+
+We haven't resolved all the issues yet, but we are working on it which could happen in the next major version (v5): <https://github.com/un-ts/eslint-plugin-import-x/issues/235>.
+
+## Differences
+
+So what's the differences from `eslint-plugin-import` exactly?
+
+- we target [Node `^18.18.0 || ^20.9.0 || >=21.1.0`](https://github.com/un-ts/eslint-plugin-import-x/blob/8b2d6d3b612eb57fb68c3fddec25b02fc622df7c/package.json#L12) + [ESLint `^8.57.0 || ^9.0.0`](https://github.com/un-ts/eslint-plugin-import-x/blob/8b2d6d3b612eb57fb68c3fddec25b02fc622df7c/package.json#L71), while `eslint-plugin-import` targets [Node `>=4`](https://github.com/import-js/eslint-plugin-import/blob/da5f6ec13160cb288338db0c2a00c34b2d932f0d/package.json#L6) and [ESLint `^2 || ^3 || ^4 || ^5 || ^6 || ^7.2.0 || ^8 || ^9`](https://github.com/import-js/eslint-plugin-import/blob/da5f6ec13160cb288338db0c2a00c34b2d932f0d/package.json#L115C16-L115C64)
+- we don't depend on old and outdated dependencies, so we have short dependency depths, see also <https://github.com/un-ts/eslint-plugin-import-x/pull/11>
+- `eslint-plugin-import` uses `tsconfig-paths` + `typescript` itself to load `tsconfig`s while we use the single `get-tsconfig` instead, which is much faster and cleaner
+- `eslint-plugin-import` uses [`resolve`] which doesn't support `exports` field in `package.json` while we use [`unrs-resolver`] instead, which is a [napi-rs] project so it's much faster
+- Our [v3 resolver](./resolvers/README.md#v3) interface shares a single `resolver` instance by default which is used all across resolving chains so it would benefit from caching and memoization out of box
+- ...
+
+The list could be longer in the future, but we don't want to make it too long here, hope you enjoy and let's get started.
path: README.md
user: login: benmccann
body: ```suggestion
The list could be longer in the future, but we don't want to make it too long here. Hope you enjoy and let's get started.
```
created_at: 2025-05-15T03:17:46Z
author_association: CONTRIBUTOR
diff_hunk: @@ -50,6 +54,33 @@
 - [Changelog](#changelog)
 - [License](#license)
 
+## Why
+
+A lot of issues can not be fixed easily without API changes. E.g. see:
+
+- <https://github.com/import-js/eslint-plugin-import/issues/1479>
+- <https://github.com/import-js/eslint-plugin-import/issues/2108>
+- <https://github.com/import-js/eslint-plugin-import/issues/2111>
+
+[`eslint-plugin-import`] refused to accept BREAKING CHANGES for these issues, so we had to fork it.
+
+[`eslint-plugin-import`] now claims in <https://github.com/un-ts/eslint-plugin-import-x/issues/170> that it will accept BREAKING CHANGES. However, still nothing is happening: <https://github.com/import-js/eslint-plugin-import/pull/3091>.
+
+We haven't resolved all the issues yet, but we are working on it which could happen in the next major version (v5): <https://github.com/un-ts/eslint-plugin-import-x/issues/235>.
+
path: README.md
user: login: coderabbitai[bot]
body: _🛠️ Refactor suggestion_

**Polish the “Why” section for grammar and style**  
- Change “A lot of issues can not” to “Many issues cannot” for conciseness and correctness.  
- Use “For example” instead of “E.g.” at the start of a sentence and add a comma.  
- Add a comma before “which” in line 69 to set off the relative clause.  
Consider this rewrite:  
```markdown
## Why

Many issues cannot be fixed easily without breaking API changes. For example, see:

- <https://github.com/import-js/eslint-plugin-import/issues/1479>
- <https://github.com/import-js/eslint-plugin-import/issues/2108>
- <https://github.com/import-js/eslint-plugin-import/issues/2111>

Because [`eslint-plugin-import`] refused to accept these breaking changes, we forked the project.

Although [`eslint-plugin-import`] now claims in <https://github.com/un-ts/eslint-plugin-import-x/issues/170> that it will accept breaking changes, no progress has been made: <https://github.com/import-js/eslint-plugin-import/pull/3091>.

We haven’t resolved all issues yet, but we are working on them, which could happen in the next major version (v5): <https://github.com/un-ts/eslint-plugin-import-x/issues/235>.
```

<details>
<summary>🧰 Tools</summary>

<details>
<summary>🪛 LanguageTool</summary>

[style] ~58-~58: Consider using a synonym to be more concise.
Context: ...angelog) - [License](#license)  ## Why  A lot of issues can not be fixed easily without ...

(A_LOT_OF)

---

[style] ~59-~59: Unless you want to emphasize “not”, use “cannot” which is more common.
Context: ...nse](#license)  ## Why  A lot of issues can not be fixed easily without API changes. E....

(CAN_NOT_PREMIUM)

---

[style] ~59-~59: Consider using a different verb for a more formal wording.
Context: ...se)  ## Why  A lot of issues can not be fixed easily without API changes. E.g. see:  ...

(FIX_RESOLVE)

---

[uncategorized] ~69-~69: Possible missing comma found.
Context: ...l the issues yet, but we are working on it which could happen in the next major ve...

(AI_HYDRA_LEO_MISSING_COMMA)

</details>

</details>

<details>
<summary>🤖 Prompt for AI Agents</summary>

```
In README.md around lines 57 to 70, improve grammar and style in the "Why"
section by changing "A lot of issues can not" to "Many issues cannot," replacing
"E.g." with "For example," adding a comma after "For example," and inserting a
comma before "which" in the last sentence. Also, rephrase sentences for clarity
and conciseness as suggested in the provided rewrite, ensuring consistent
capitalization and punctuation throughout the section.
```

</details>

<!-- This is an auto-generated comment by CodeRabbit -->
created_at: 2025-05-15T03:40:47Z
author_association: CONTRIBUTOR
diff_hunk: @@ -50,6 +54,33 @@ This plugin intends to support linting of ES2015+ (ES6+) import/export syntax, a
 - [Changelog](#changelog)
 - [License](#license)
 
+## Why
+
+Many issues cannot be fixed easily without API changes. For example, see:
+
+- <https://github.com/import-js/eslint-plugin-import/issues/1479>
+- <https://github.com/import-js/eslint-plugin-import/issues/2108>
+- <https://github.com/import-js/eslint-plugin-import/issues/2111>
+
+[`eslint-plugin-import`] refused to accept BREAKING CHANGES for these issues, so we had to fork it.
+
+[`eslint-plugin-import`] now claims in <https://github.com/un-ts/eslint-plugin-import-x/issues/170> that it will accept BREAKING CHANGES. However, still nothing is happening: <https://github.com/import-js/eslint-plugin-import/pull/3091>.
+
+We haven't resolved all the issues yet, but we are working on them, which could happen in the next major version (v5): <https://github.com/un-ts/eslint-plugin-import-x/issues/235>.
path: README.md
user: login: SukkaW
body: Also mentioning that ljharb simply refuses to implement the `exports` feature in the node resolver and even locks the feature request issue https://github.com/import-js/eslint-plugin-import/issues/1810. On the other hand, `eslint-plugin-import-x` now provides first-party support for the `exports` and will become default in the next major version.
created_at: 2025-05-15T07:47:45Z
author_association: COLLABORATOR
diff_hunk: @@ -50,6 +54,33 @@ This plugin intends to support linting of ES2015+ (ES6+) import/export syntax, a
 - [Changelog](#changelog)
 - [License](#license)
 
+## Why
+
+Many issues cannot be fixed easily without API changes. For example, see:
+
+- <https://github.com/import-js/eslint-plugin-import/issues/1479>
+- <https://github.com/import-js/eslint-plugin-import/issues/2108>
+- <https://github.com/import-js/eslint-plugin-import/issues/2111>
+
+[`eslint-plugin-import`] refused to accept BREAKING CHANGES for these issues, so we had to fork it.
+
+[`eslint-plugin-import`] now claims in <https://github.com/un-ts/eslint-plugin-import-x/issues/170> that it will accept BREAKING CHANGES. However, still nothing is happening: <https://github.com/import-js/eslint-plugin-import/pull/3091>.
+
+We haven't resolved all the issues yet, but we are working on them, which could happen in the next major version (v5): <https://github.com/un-ts/eslint-plugin-import-x/issues/235>.
path: README.md
user: login: JounQin
body: @SukkaW Would you like to provide a diff suggestion instead?
created_at: 2025-05-15T07:49:19Z
author_association: MEMBER
diff_hunk: @@ -50,6 +54,33 @@ This plugin intends to support linting of ES2015+ (ES6+) import/export syntax, a
 - [Changelog](#changelog)
 - [License](#license)
 
+## Why
+
+Many issues cannot be fixed easily without API changes. For example, see:
+
+- <https://github.com/import-js/eslint-plugin-import/issues/1479>
+- <https://github.com/import-js/eslint-plugin-import/issues/2108>
+- <https://github.com/import-js/eslint-plugin-import/issues/2111>
+
+[`eslint-plugin-import`] refused to accept BREAKING CHANGES for these issues, so we had to fork it.
+
+[`eslint-plugin-import`] now claims in <https://github.com/un-ts/eslint-plugin-import-x/issues/170> that it will accept BREAKING CHANGES. However, still nothing is happening: <https://github.com/import-js/eslint-plugin-import/pull/3091>.
+
+We haven't resolved all the issues yet, but we are working on them, which could happen in the next major version (v5): <https://github.com/un-ts/eslint-plugin-import-x/issues/235>.
+
+## Differences
+
+So what are the differences from `eslint-plugin-import` exactly?
+
+- we target [Node `^18.18.0 || ^20.9.0 || >=21.1.0`](https://github.com/un-ts/eslint-plugin-import-x/blob/8b2d6d3b612eb57fb68c3fddec25b02fc622df7c/package.json#L12) + [ESLint `^8.57.0 || ^9.0.0`](https://github.com/un-ts/eslint-plugin-import-x/blob/8b2d6d3b612eb57fb68c3fddec25b02fc622df7c/package.json#L71), while `eslint-plugin-import` targets [Node `>=4`](https://github.com/import-js/eslint-plugin-import/blob/da5f6ec13160cb288338db0c2a00c34b2d932f0d/package.json#L6) and [ESLint `^2 || ^3 || ^4 || ^5 || ^6 || ^7.2.0 || ^8 || ^9`](https://github.com/import-js/eslint-plugin-import/blob/da5f6ec13160cb288338db0c2a00c34b2d932f0d/package.json#L115C16-L115C64)
+- we don't depend on old and outdated dependencies, so [we have 49 dependencies](https://npmgraph.js.org/?q=eslint-plugin-import-x) compared to [117 dependencies for `eslint-plugin-import`](https://npmgraph.js.org/?q=eslint-plugin-import)
+- `eslint-plugin-import` uses `tsconfig-paths` + `typescript` itself to load `tsconfig`s while we use the single `get-tsconfig` instead, which is much faster and cleaner
+- `eslint-plugin-import` uses [`resolve`] which doesn't support the `exports` field in `package.json` while we use [`unrs-resolver`] instead, which does support it and is a [`napi-rs`] project so is also much faster
path: README.md
user: login: SukkaW
body: ```suggestion
- `eslint-plugin-import` uses [`resolve`] which doesn't support the `exports` field in `package.json` while we build our own rust-based resolver [`unrs-resolver`] instead, which is feature-rich and way more performant.
```
created_at: 2025-05-15T07:49:20Z
author_association: COLLABORATOR
diff_hunk: @@ -50,6 +54,33 @@ This plugin intends to support linting of ES2015+ (ES6+) import/export syntax, a
 - [Changelog](#changelog)
 - [License](#license)
 
+## Why
+
+Many issues cannot be fixed easily without API changes. For example, see:
+
+- <https://github.com/import-js/eslint-plugin-import/issues/1479>
+- <https://github.com/import-js/eslint-plugin-import/issues/2108>
+- <https://github.com/import-js/eslint-plugin-import/issues/2111>
+
+[`eslint-plugin-import`] refused to accept BREAKING CHANGES for these issues, so we had to fork it.
+
+[`eslint-plugin-import`] now claims in <https://github.com/un-ts/eslint-plugin-import-x/issues/170> that it will accept BREAKING CHANGES. However, still nothing is happening: <https://github.com/import-js/eslint-plugin-import/pull/3091>.
+
+We haven't resolved all the issues yet, but we are working on them, which could happen in the next major version (v5): <https://github.com/un-ts/eslint-plugin-import-x/issues/235>.
path: README.md
user: login: SukkaW
body: ```suggestion
[`eslint-plugin-import`] refuses to support the `exports` feature, and the maintainer even locked the feature request issue <https://github.com/import-js/eslint-plugin-import/issues/1810> to prevent future discussion. In the meantime, `eslint-plugin-import-x` now provides first-party support for the `exports` feature <https://github.com/un-ts/eslint-plugin-import-x/pull/209>, which will become the default in the next major version (v5).

We haven't resolved all the issues yet, but we are working on them, which could happen in the next major version (v5): <https://github.com/un-ts/eslint-plugin-import-x/issues/235>.
```
created_at: 2025-05-15T07:59:39Z
author_association: COLLABORATOR
path: README.md
user: login: JoshuaKGoldberg
body: Ah I've been swamped this week but hoped to get to reviewing this before merge. Filing a bookmark to come back to you with a review soon. Sorry for the delay!
created_at: 2025-05-16T12:05:33Z
author_association: CONTRIBUTOR
diff_hunk: @@ -14,12 +14,16 @@
 
 This plugin intends to support linting of ES2015+ (ES6+) import/export syntax, and prevent issues with misspelling of file paths and import names. All the goodness that the ES2015+ static module syntax intends to provide, marked up in your editor.
 
+It started as a fork of [`eslint-plugin-import`] using [`get-tsconfig`] to replace [`tsconfig-paths`] and heavy [`typescript`] under the hood, making it faster, through less [heavy dependency on Typescript](https://github.com/import-js/eslint-plugin-import/blob/da5f6ec13160cb288338db0c2a00c34b2d932f0d/src/exportMap/typescript.js#L16), and cleaner dependencies altogether.
path: README.md
user: login: JoshuaKGoldberg
body: > to replace `tsconfig-paths` and heavy `typescript` under the hood, making it faster

* How?
* Why?
created_at: 2025-05-20T13:02:39Z
author_association: CONTRIBUTOR
diff_hunk: @@ -50,6 +54,35 @@ This plugin intends to support linting of ES2015+ (ES6+) import/export syntax, a
 - [Changelog](#changelog)
 - [License](#license)
 
+## Why
+
+Many issues cannot be fixed easily without API changes. For example, see:
+
+- <https://github.com/import-js/eslint-plugin-import/issues/1479>
+- <https://github.com/import-js/eslint-plugin-import/issues/2108>
+- <https://github.com/import-js/eslint-plugin-import/issues/2111>
path: README.md
user: login: JoshuaKGoldberg
body: (more on this on the next line) Having three issue links is a good start, but all three require a ton of reading. Two are labeled as `help wanted`. Someone cursorily reading these docs could easily come away with the conclusion that these issues are just pending in upstream, not actually blockers.
created_at: 2025-05-20T13:06:41Z
author_association: CONTRIBUTOR
diff_hunk: @@ -50,6 +54,35 @@ This plugin intends to support linting of ES2015+ (ES6+) import/export syntax, a
 - [Changelog](#changelog)
 - [License](#license)
 
+## Why
+
+Many issues cannot be fixed easily without API changes. For example, see:
+
+- <https://github.com/import-js/eslint-plugin-import/issues/1479>
+- <https://github.com/import-js/eslint-plugin-import/issues/2108>
+- <https://github.com/import-js/eslint-plugin-import/issues/2111>
+
+[`eslint-plugin-import`] refused to accept BREAKING CHANGES for these issues, so we had to fork it.
path: README.md
user: login: JoshuaKGoldberg
body: This sentence might be accurate, but it's not precise. Saying someone "refused" and you "had to fork" could mean a lot of things. As a result I think it sounds accusatory, even though that's not the intent. "refused" is a loaded word!

I think what this line is really trying to get at is why it is/was difficult to get these changes upstream. Right?

https://github.com/import-js/eslint-plugin-import/issues/1479#issuecomment-783094870 & https://github.com/import-js/eslint-plugin-import/issues/1479#issuecomment-784468166 -> the issue is marked as `help wanted` and there is no linked PR. So it's that it's just difficult & more work to satisfy the upstream's constraints, right?

https://github.com/import-js/eslint-plugin-import/issues/2108#issuecomment-1205592491 -> https://github.com/import-js/eslint-plugin-import/issues/2108#issuecomment-1205864116: same thing but with a draft PR that has a pending question. So it's similarly that it's just difficult & more work to work with their constraints, right?

https://github.com/import-js/eslint-plugin-import/issues/2111: same thing with https://github.com/import-js/eslint-plugin-import/issues/2111#issuecomment-1063073028, just a 'no breaking changes' constraint that makes the design space harder?

Here's a first draft at a rewrite...

```suggestion
[`eslint-plugin-import`] prioritizes long backwards compatibility over than accepting breaking changes for these issues.
Efforts to resolve the issues in backwards-compatible ways upstreajm have stalled for several years.
This fork was created to have a plugin that does not have the same backwards compatibility requirements and so can more easily work for more modern codebases
```

...but I'm not confident that that rewrite is 100% right. I'm trying to convey exactly the technical reasons without implying any "blame". More word-crafting is probably required.
created_at: 2025-05-20T13:58:16Z
author_association: CONTRIBUTOR
diff_hunk: @@ -50,6 +54,35 @@ This plugin intends to support linting of ES2015+ (ES6+) import/export syntax, a
 - [Changelog](#changelog)
 - [License](#license)
 
+## Why
+
+Many issues cannot be fixed easily without API changes. For example, see:
+
+- <https://github.com/import-js/eslint-plugin-import/issues/1479>
+- <https://github.com/import-js/eslint-plugin-import/issues/2108>
+- <https://github.com/import-js/eslint-plugin-import/issues/2111>
+
+[`eslint-plugin-import`] refused to accept BREAKING CHANGES for these issues, so we had to fork it.
+
+[`eslint-plugin-import`] now claims in <https://github.com/un-ts/eslint-plugin-import-x/issues/170> that it will accept BREAKING CHANGES. However, still nothing is happening: <https://github.com/import-js/eslint-plugin-import/pull/3091>.
path: README.md
user: login: JoshuaKGoldberg
body: Have you checked with ljharb? Is this just pending review? As an outsider, seeing a 7 month old semver-major PR without review makes me think there's some intrigue behind-the-scenes I'm not privy to. 
created_at: 2025-05-20T13:59:51Z
author_association: CONTRIBUTOR
diff_hunk: @@ -50,6 +54,35 @@ This plugin intends to support linting of ES2015+ (ES6+) import/export syntax, a
 - [Changelog](#changelog)
 - [License](#license)
 
+## Why
+
+Many issues cannot be fixed easily without API changes. For example, see:
+
+- <https://github.com/import-js/eslint-plugin-import/issues/1479>
+- <https://github.com/import-js/eslint-plugin-import/issues/2108>
+- <https://github.com/import-js/eslint-plugin-import/issues/2111>
+
+[`eslint-plugin-import`] refused to accept BREAKING CHANGES for these issues, so we had to fork it.
+
+[`eslint-plugin-import`] now claims in <https://github.com/un-ts/eslint-plugin-import-x/issues/170> that it will accept BREAKING CHANGES. However, still nothing is happening: <https://github.com/import-js/eslint-plugin-import/pull/3091>.
+
+[`eslint-plugin-import`] refuses to support the `exports` feature, and the maintainer even locked the feature request issue <https://github.com/import-js/eslint-plugin-import/issues/1810> to prevent future discussion. In the meantime, `eslint-plugin-import-x` now provides first-party support for the `exports` feature <https://github.com/un-ts/eslint-plugin-import-x/pull/209>, which will become the default in the next major version (v5).
path: README.md
user: login: JoshuaKGoldberg
body: > refuses

It looks to me like the root issue of fixing `resolve` (https://github.com/browserify/resolve/pull/224) is what was indicated as the desired fix, and that is similarly stalled due to difficulties in supporting the repo's long backwards compatibility requirements, yeah? So it's not that they're refusing, it's actively accepting - just difficult?

> ... to prevent future discussion

My read of https://github.com/import-js/eslint-plugin-import/issues/1810#issuecomment-1818010790 was that the lock was because one particular person was repeatedly arguming with the maintainer on that one day, and the conversation was getting heated & off-topic? The _"for a bit"_ makes me think the conversation was supposed to be un-locked and that just never happened, unintentionally. Maybe now is the time for a ping to re-open?
created_at: 2025-05-20T14:05:06Z
author_association: CONTRIBUTOR
diff_hunk: @@ -50,6 +54,35 @@ This plugin intends to support linting of ES2015+ (ES6+) import/export syntax, a
 - [Changelog](#changelog)
 - [License](#license)
 
+## Why
+
+Many issues cannot be fixed easily without API changes. For example, see:
+
+- <https://github.com/import-js/eslint-plugin-import/issues/1479>
+- <https://github.com/import-js/eslint-plugin-import/issues/2108>
+- <https://github.com/import-js/eslint-plugin-import/issues/2111>
+
+[`eslint-plugin-import`] refused to accept BREAKING CHANGES for these issues, so we had to fork it.
+
+[`eslint-plugin-import`] now claims in <https://github.com/un-ts/eslint-plugin-import-x/issues/170> that it will accept BREAKING CHANGES. However, still nothing is happening: <https://github.com/import-js/eslint-plugin-import/pull/3091>.
+
+[`eslint-plugin-import`] refuses to support the `exports` feature, and the maintainer even locked the feature request issue <https://github.com/import-js/eslint-plugin-import/issues/1810> to prevent future discussion. In the meantime, `eslint-plugin-import-x` now provides first-party support for the `exports` feature <https://github.com/un-ts/eslint-plugin-import-x/pull/209>, which will become the default in the next major version (v5).
+
+We haven't resolved all the issues yet, but we are working on them, which could happen in the next major version (v5): <https://github.com/un-ts/eslint-plugin-import-x/issues/235>.
+
+## Differences
+
+So what are the differences from `eslint-plugin-import` exactly?
+
+- we target [Node `^18.18.0 || ^20.9.0 || >=21.1.0`](https://github.com/un-ts/eslint-plugin-import-x/blob/8b2d6d3b612eb57fb68c3fddec25b02fc622df7c/package.json#L12) + [ESLint `^8.57.0 || ^9.0.0`](https://github.com/un-ts/eslint-plugin-import-x/blob/8b2d6d3b612eb57fb68c3fddec25b02fc622df7c/package.json#L71), while `eslint-plugin-import` targets [Node `>=4`](https://github.com/import-js/eslint-plugin-import/blob/da5f6ec13160cb288338db0c2a00c34b2d932f0d/package.json#L6) and [ESLint `^2 || ^3 || ^4 || ^5 || ^6 || ^7.2.0 || ^8 || ^9`](https://github.com/import-js/eslint-plugin-import/blob/da5f6ec13160cb288338db0c2a00c34b2d932f0d/package.json#L115C16-L115C64)
+- we don't depend on old and outdated dependencies, so [we have 49 dependencies](https://npmgraph.js.org/?q=eslint-plugin-import-x) compared to [117 dependencies for `eslint-plugin-import`](https://npmgraph.js.org/?q=eslint-plugin-import)
path: README.md
user: login: JoshuaKGoldberg
body: Data request: the counts and links to npmgraph are a good start, but don't immediately describe what the _real impact_ is. Dependency tree size is abstract and vague, and not an end-user metric (e.g. 1 of the 49 dependencies might be larger than all of the opposing 117 combined).

In order to get to any end-user-relevant info such as the actual unpacked module size you have to know to:

1. Open both links
2. Click on the root plugins in the visualizer
3. Find each _Module Size_ > _Unpacked Size (module + dependencies)_

I think most readers will not do that, so calling out the 6 MB vs 36 MB comparison here would be required for getting it known.


created_at: 2025-05-20T14:11:20Z
author_association: CONTRIBUTOR
diff_hunk: @@ -50,6 +54,35 @@ This plugin intends to support linting of ES2015+ (ES6+) import/export syntax, a
 - [Changelog](#changelog)
 - [License](#license)
 
+## Why
+
+Many issues cannot be fixed easily without API changes. For example, see:
+
+- <https://github.com/import-js/eslint-plugin-import/issues/1479>
+- <https://github.com/import-js/eslint-plugin-import/issues/2108>
+- <https://github.com/import-js/eslint-plugin-import/issues/2111>
+
+[`eslint-plugin-import`] refused to accept BREAKING CHANGES for these issues, so we had to fork it.
+
+[`eslint-plugin-import`] now claims in <https://github.com/un-ts/eslint-plugin-import-x/issues/170> that it will accept BREAKING CHANGES. However, still nothing is happening: <https://github.com/import-js/eslint-plugin-import/pull/3091>.
+
+[`eslint-plugin-import`] refuses to support the `exports` feature, and the maintainer even locked the feature request issue <https://github.com/import-js/eslint-plugin-import/issues/1810> to prevent future discussion. In the meantime, `eslint-plugin-import-x` now provides first-party support for the `exports` feature <https://github.com/un-ts/eslint-plugin-import-x/pull/209>, which will become the default in the next major version (v5).
+
+We haven't resolved all the issues yet, but we are working on them, which could happen in the next major version (v5): <https://github.com/un-ts/eslint-plugin-import-x/issues/235>.
+
+## Differences
+
+So what are the differences from `eslint-plugin-import` exactly?
+
+- we target [Node `^18.18.0 || ^20.9.0 || >=21.1.0`](https://github.com/un-ts/eslint-plugin-import-x/blob/8b2d6d3b612eb57fb68c3fddec25b02fc622df7c/package.json#L12) + [ESLint `^8.57.0 || ^9.0.0`](https://github.com/un-ts/eslint-plugin-import-x/blob/8b2d6d3b612eb57fb68c3fddec25b02fc622df7c/package.json#L71), while `eslint-plugin-import` targets [Node `>=4`](https://github.com/import-js/eslint-plugin-import/blob/da5f6ec13160cb288338db0c2a00c34b2d932f0d/package.json#L6) and [ESLint `^2 || ^3 || ^4 || ^5 || ^6 || ^7.2.0 || ^8 || ^9`](https://github.com/import-js/eslint-plugin-import/blob/da5f6ec13160cb288338db0c2a00c34b2d932f0d/package.json#L115C16-L115C64)
+- we don't depend on old and outdated dependencies, so [we have 49 dependencies](https://npmgraph.js.org/?q=eslint-plugin-import-x) compared to [117 dependencies for `eslint-plugin-import`](https://npmgraph.js.org/?q=eslint-plugin-import)
+- `eslint-plugin-import` uses `tsconfig-paths` + `typescript` itself to load `tsconfig`s while we use the single `get-tsconfig` instead, which is much faster and cleaner
path: README.md
user: login: JoshuaKGoldberg
body: > much faster

Prove it! Show me the data! 😄

As a developer, I have been trained to not believe any performance comparison not backed up by data. One should always back perf comparisons up with repeatable experiments.

Note that isolated experiments in `get-tsconfig` itself are not enough. The package might be fast in isolation but equal -or even slower!- in real-world usage. I need actual data from this specific plugin use case. 
created_at: 2025-05-20T14:14:03Z
author_association: CONTRIBUTOR
diff_hunk: @@ -50,6 +54,35 @@ This plugin intends to support linting of ES2015+ (ES6+) import/export syntax, a
 - [Changelog](#changelog)
 - [License](#license)
 
+## Why
+
+Many issues cannot be fixed easily without API changes. For example, see:
+
+- <https://github.com/import-js/eslint-plugin-import/issues/1479>
+- <https://github.com/import-js/eslint-plugin-import/issues/2108>
+- <https://github.com/import-js/eslint-plugin-import/issues/2111>
+
+[`eslint-plugin-import`] refused to accept BREAKING CHANGES for these issues, so we had to fork it.
+
+[`eslint-plugin-import`] now claims in <https://github.com/un-ts/eslint-plugin-import-x/issues/170> that it will accept BREAKING CHANGES. However, still nothing is happening: <https://github.com/import-js/eslint-plugin-import/pull/3091>.
+
+[`eslint-plugin-import`] refuses to support the `exports` feature, and the maintainer even locked the feature request issue <https://github.com/import-js/eslint-plugin-import/issues/1810> to prevent future discussion. In the meantime, `eslint-plugin-import-x` now provides first-party support for the `exports` feature <https://github.com/un-ts/eslint-plugin-import-x/pull/209>, which will become the default in the next major version (v5).
+
+We haven't resolved all the issues yet, but we are working on them, which could happen in the next major version (v5): <https://github.com/un-ts/eslint-plugin-import-x/issues/235>.
+
+## Differences
+
+So what are the differences from `eslint-plugin-import` exactly?
+
+- we target [Node `^18.18.0 || ^20.9.0 || >=21.1.0`](https://github.com/un-ts/eslint-plugin-import-x/blob/8b2d6d3b612eb57fb68c3fddec25b02fc622df7c/package.json#L12) + [ESLint `^8.57.0 || ^9.0.0`](https://github.com/un-ts/eslint-plugin-import-x/blob/8b2d6d3b612eb57fb68c3fddec25b02fc622df7c/package.json#L71), while `eslint-plugin-import` targets [Node `>=4`](https://github.com/import-js/eslint-plugin-import/blob/da5f6ec13160cb288338db0c2a00c34b2d932f0d/package.json#L6) and [ESLint `^2 || ^3 || ^4 || ^5 || ^6 || ^7.2.0 || ^8 || ^9`](https://github.com/import-js/eslint-plugin-import/blob/da5f6ec13160cb288338db0c2a00c34b2d932f0d/package.json#L115C16-L115C64)
+- we don't depend on old and outdated dependencies, so [we have 49 dependencies](https://npmgraph.js.org/?q=eslint-plugin-import-x) compared to [117 dependencies for `eslint-plugin-import`](https://npmgraph.js.org/?q=eslint-plugin-import)
+- `eslint-plugin-import` uses `tsconfig-paths` + `typescript` itself to load `tsconfig`s while we use the single `get-tsconfig` instead, which is much faster and cleaner
+- `eslint-plugin-import` uses [`resolve`] which doesn't support the `exports` field in `package.json` while we build our own rust-based resolver [`unrs-resolver`] instead, which is feature-rich and way more performant.
path: README.md
user: login: JoshuaKGoldberg
body: > feature-rich

This is abstract and non-tangible: what do you mean? How is this relevant to a reader?
created_at: 2025-05-20T14:14:29Z
author_association: CONTRIBUTOR
diff_hunk: @@ -50,6 +54,35 @@ This plugin intends to support linting of ES2015+ (ES6+) import/export syntax, a
 - [Changelog](#changelog)
 - [License](#license)
 
+## Why
+
+Many issues cannot be fixed easily without API changes. For example, see:
+
+- <https://github.com/import-js/eslint-plugin-import/issues/1479>
+- <https://github.com/import-js/eslint-plugin-import/issues/2108>
+- <https://github.com/import-js/eslint-plugin-import/issues/2111>
+
+[`eslint-plugin-import`] refused to accept BREAKING CHANGES for these issues, so we had to fork it.
+
+[`eslint-plugin-import`] now claims in <https://github.com/un-ts/eslint-plugin-import-x/issues/170> that it will accept BREAKING CHANGES. However, still nothing is happening: <https://github.com/import-js/eslint-plugin-import/pull/3091>.
+
+[`eslint-plugin-import`] refuses to support the `exports` feature, and the maintainer even locked the feature request issue <https://github.com/import-js/eslint-plugin-import/issues/1810> to prevent future discussion. In the meantime, `eslint-plugin-import-x` now provides first-party support for the `exports` feature <https://github.com/un-ts/eslint-plugin-import-x/pull/209>, which will become the default in the next major version (v5).
+
+We haven't resolved all the issues yet, but we are working on them, which could happen in the next major version (v5): <https://github.com/un-ts/eslint-plugin-import-x/issues/235>.
+
+## Differences
+
+So what are the differences from `eslint-plugin-import` exactly?
+
+- we target [Node `^18.18.0 || ^20.9.0 || >=21.1.0`](https://github.com/un-ts/eslint-plugin-import-x/blob/8b2d6d3b612eb57fb68c3fddec25b02fc622df7c/package.json#L12) + [ESLint `^8.57.0 || ^9.0.0`](https://github.com/un-ts/eslint-plugin-import-x/blob/8b2d6d3b612eb57fb68c3fddec25b02fc622df7c/package.json#L71), while `eslint-plugin-import` targets [Node `>=4`](https://github.com/import-js/eslint-plugin-import/blob/da5f6ec13160cb288338db0c2a00c34b2d932f0d/package.json#L6) and [ESLint `^2 || ^3 || ^4 || ^5 || ^6 || ^7.2.0 || ^8 || ^9`](https://github.com/import-js/eslint-plugin-import/blob/da5f6ec13160cb288338db0c2a00c34b2d932f0d/package.json#L115C16-L115C64)
+- we don't depend on old and outdated dependencies, so [we have 49 dependencies](https://npmgraph.js.org/?q=eslint-plugin-import-x) compared to [117 dependencies for `eslint-plugin-import`](https://npmgraph.js.org/?q=eslint-plugin-import)
+- `eslint-plugin-import` uses `tsconfig-paths` + `typescript` itself to load `tsconfig`s while we use the single `get-tsconfig` instead, which is much faster and cleaner
path: README.md
user: login: JoshuaKGoldberg
body: > cleaner

Why would an end-user care about this? 
created_at: 2025-05-20T14:14:40Z
author_association: CONTRIBUTOR
diff_hunk: @@ -14,12 +14,16 @@
 
 This plugin intends to support linting of ES2015+ (ES6+) import/export syntax, and prevent issues with misspelling of file paths and import names. All the goodness that the ES2015+ static module syntax intends to provide, marked up in your editor.
 
+It started as a fork of [`eslint-plugin-import`] using [`get-tsconfig`] to replace [`tsconfig-paths`] and heavy [`typescript`] under the hood, making it faster, through less [heavy dependency on Typescript](https://github.com/import-js/eslint-plugin-import/blob/da5f6ec13160cb288338db0c2a00c34b2d932f0d/src/exportMap/typescript.js#L16), and cleaner dependencies altogether.
path: README.md
user: login: JounQin
body: > How?

replace `tsconfig-paths` and heavy `typescript` with single [`get-tsconfig`](https://github.com/privatenumber/get-tsconfig)?

> Why?

`typescript` is heavy to load at https://github.com/import-js/eslint-plugin-import/blob/da5f6ec13160cb288338db0c2a00c34b2d932f0d/src/exportMap/typescript.js#L16
created_at: 2025-05-20T14:36:28Z
author_association: MEMBER
diff_hunk: @@ -50,6 +54,35 @@ This plugin intends to support linting of ES2015+ (ES6+) import/export syntax, a
 - [Changelog](#changelog)
 - [License](#license)
 
+## Why
+
+Many issues cannot be fixed easily without API changes. For example, see:
+
+- <https://github.com/import-js/eslint-plugin-import/issues/1479>
+- <https://github.com/import-js/eslint-plugin-import/issues/2108>
+- <https://github.com/import-js/eslint-plugin-import/issues/2111>
+
+[`eslint-plugin-import`] refused to accept BREAKING CHANGES for these issues, so we had to fork it.
path: README.md
user: login: JounQin
body: > https://github.com/import-js/eslint-plugin-import/issues/2108#issuecomment-1205592491 -> https://github.com/import-js/eslint-plugin-import/issues/2108#issuecomment-1205864116: same thing but with a draft PR that has a pending question. So it's similarly that it's just difficult & more work to work with their constraints, right?

I don't get what's blocking the PR actually. All tests are passing. And when the maintainer says "is this potentially a breaking change", I just don't want to continue that PR.

All possible breaking changes are refused. All the issues are in the same condition IMO.

cc @benmccann @43081j 
created_at: 2025-05-20T14:42:31Z
author_association: MEMBER
diff_hunk: @@ -50,6 +54,35 @@ This plugin intends to support linting of ES2015+ (ES6+) import/export syntax, a
 - [Changelog](#changelog)
 - [License](#license)
 
+## Why
+
+Many issues cannot be fixed easily without API changes. For example, see:
+
+- <https://github.com/import-js/eslint-plugin-import/issues/1479>
+- <https://github.com/import-js/eslint-plugin-import/issues/2108>
+- <https://github.com/import-js/eslint-plugin-import/issues/2111>
+
+[`eslint-plugin-import`] refused to accept BREAKING CHANGES for these issues, so we had to fork it.
+
+[`eslint-plugin-import`] now claims in <https://github.com/un-ts/eslint-plugin-import-x/issues/170> that it will accept BREAKING CHANGES. However, still nothing is happening: <https://github.com/import-js/eslint-plugin-import/pull/3091>.
path: README.md
user: login: JounQin
body: > Have you checked with ljharb?

Why should I/we do that, we've already moved away for a long time?
created_at: 2025-05-20T14:43:42Z
author_association: MEMBER
diff_hunk: @@ -50,6 +54,35 @@ This plugin intends to support linting of ES2015+ (ES6+) import/export syntax, a
 - [Changelog](#changelog)
 - [License](#license)
 
+## Why
+
+Many issues cannot be fixed easily without API changes. For example, see:
+
+- <https://github.com/import-js/eslint-plugin-import/issues/1479>
+- <https://github.com/import-js/eslint-plugin-import/issues/2108>
+- <https://github.com/import-js/eslint-plugin-import/issues/2111>
+
+[`eslint-plugin-import`] refused to accept BREAKING CHANGES for these issues, so we had to fork it.
+
+[`eslint-plugin-import`] now claims in <https://github.com/un-ts/eslint-plugin-import-x/issues/170> that it will accept BREAKING CHANGES. However, still nothing is happening: <https://github.com/import-js/eslint-plugin-import/pull/3091>.
+
+[`eslint-plugin-import`] refuses to support the `exports` feature, and the maintainer even locked the feature request issue <https://github.com/import-js/eslint-plugin-import/issues/1810> to prevent future discussion. In the meantime, `eslint-plugin-import-x` now provides first-party support for the `exports` feature <https://github.com/un-ts/eslint-plugin-import-x/pull/209>, which will become the default in the next major version (v5).
path: README.md
user: login: JounQin
body: > So it's not that they're refusing, it's actively accepting - just difficult?

Difficult due to backward compatibility, so it's just refusing.

> My read of https://github.com/import-js/eslint-plugin-import/issues/1810#issuecomment-1818010790 was that the lock was because one particular person was repeatedly arguming with the maintainer on that one day, and the conversation was getting heated & off-topic? The "for a bit" makes me think the conversation was supposed to be un-locked and that just never happened, unintentionally. Maybe now is the time for a ping to re-open?

You may help to reconstruct the sentence, it's just our feelings, everyone could have different feelings.

> Maybe now is the time for a ping to re-open?

Feel free to do that, while I'm not interested.
created_at: 2025-05-20T14:48:50Z
author_association: MEMBER
diff_hunk: @@ -50,6 +54,35 @@ This plugin intends to support linting of ES2015+ (ES6+) import/export syntax, a
 - [Changelog](#changelog)
 - [License](#license)
 
+## Why
+
+Many issues cannot be fixed easily without API changes. For example, see:
+
+- <https://github.com/import-js/eslint-plugin-import/issues/1479>
+- <https://github.com/import-js/eslint-plugin-import/issues/2108>
+- <https://github.com/import-js/eslint-plugin-import/issues/2111>
+
+[`eslint-plugin-import`] refused to accept BREAKING CHANGES for these issues, so we had to fork it.
+
+[`eslint-plugin-import`] now claims in <https://github.com/un-ts/eslint-plugin-import-x/issues/170> that it will accept BREAKING CHANGES. However, still nothing is happening: <https://github.com/import-js/eslint-plugin-import/pull/3091>.
+
+[`eslint-plugin-import`] refuses to support the `exports` feature, and the maintainer even locked the feature request issue <https://github.com/import-js/eslint-plugin-import/issues/1810> to prevent future discussion. In the meantime, `eslint-plugin-import-x` now provides first-party support for the `exports` feature <https://github.com/un-ts/eslint-plugin-import-x/pull/209>, which will become the default in the next major version (v5).
+
+We haven't resolved all the issues yet, but we are working on them, which could happen in the next major version (v5): <https://github.com/un-ts/eslint-plugin-import-x/issues/235>.
+
+## Differences
+
+So what are the differences from `eslint-plugin-import` exactly?
+
+- we target [Node `^18.18.0 || ^20.9.0 || >=21.1.0`](https://github.com/un-ts/eslint-plugin-import-x/blob/8b2d6d3b612eb57fb68c3fddec25b02fc622df7c/package.json#L12) + [ESLint `^8.57.0 || ^9.0.0`](https://github.com/un-ts/eslint-plugin-import-x/blob/8b2d6d3b612eb57fb68c3fddec25b02fc622df7c/package.json#L71), while `eslint-plugin-import` targets [Node `>=4`](https://github.com/import-js/eslint-plugin-import/blob/da5f6ec13160cb288338db0c2a00c34b2d932f0d/package.json#L6) and [ESLint `^2 || ^3 || ^4 || ^5 || ^6 || ^7.2.0 || ^8 || ^9`](https://github.com/import-js/eslint-plugin-import/blob/da5f6ec13160cb288338db0c2a00c34b2d932f0d/package.json#L115C16-L115C64)
+- we don't depend on old and outdated dependencies, so [we have 49 dependencies](https://npmgraph.js.org/?q=eslint-plugin-import-x) compared to [117 dependencies for `eslint-plugin-import`](https://npmgraph.js.org/?q=eslint-plugin-import)
path: README.md
user: login: JounQin
body: We'll get even less dependencies when dropping `eslint-import-resolver-node`: https://github.com/un-ts/eslint-plugin-import-x/pull/272#discussion_r2024451326
created_at: 2025-05-20T14:51:12Z
author_association: MEMBER
diff_hunk: @@ -50,6 +54,35 @@ This plugin intends to support linting of ES2015+ (ES6+) import/export syntax, a
 - [Changelog](#changelog)
 - [License](#license)
 
+## Why
+
+Many issues cannot be fixed easily without API changes. For example, see:
+
+- <https://github.com/import-js/eslint-plugin-import/issues/1479>
+- <https://github.com/import-js/eslint-plugin-import/issues/2108>
+- <https://github.com/import-js/eslint-plugin-import/issues/2111>
+
+[`eslint-plugin-import`] refused to accept BREAKING CHANGES for these issues, so we had to fork it.
+
+[`eslint-plugin-import`] now claims in <https://github.com/un-ts/eslint-plugin-import-x/issues/170> that it will accept BREAKING CHANGES. However, still nothing is happening: <https://github.com/import-js/eslint-plugin-import/pull/3091>.
+
+[`eslint-plugin-import`] refuses to support the `exports` feature, and the maintainer even locked the feature request issue <https://github.com/import-js/eslint-plugin-import/issues/1810> to prevent future discussion. In the meantime, `eslint-plugin-import-x` now provides first-party support for the `exports` feature <https://github.com/un-ts/eslint-plugin-import-x/pull/209>, which will become the default in the next major version (v5).
+
+We haven't resolved all the issues yet, but we are working on them, which could happen in the next major version (v5): <https://github.com/un-ts/eslint-plugin-import-x/issues/235>.
+
+## Differences
+
+So what are the differences from `eslint-plugin-import` exactly?
+
+- we target [Node `^18.18.0 || ^20.9.0 || >=21.1.0`](https://github.com/un-ts/eslint-plugin-import-x/blob/8b2d6d3b612eb57fb68c3fddec25b02fc622df7c/package.json#L12) + [ESLint `^8.57.0 || ^9.0.0`](https://github.com/un-ts/eslint-plugin-import-x/blob/8b2d6d3b612eb57fb68c3fddec25b02fc622df7c/package.json#L71), while `eslint-plugin-import` targets [Node `>=4`](https://github.com/import-js/eslint-plugin-import/blob/da5f6ec13160cb288338db0c2a00c34b2d932f0d/package.json#L6) and [ESLint `^2 || ^3 || ^4 || ^5 || ^6 || ^7.2.0 || ^8 || ^9`](https://github.com/import-js/eslint-plugin-import/blob/da5f6ec13160cb288338db0c2a00c34b2d932f0d/package.json#L115C16-L115C64)
+- we don't depend on old and outdated dependencies, so [we have 49 dependencies](https://npmgraph.js.org/?q=eslint-plugin-import-x) compared to [117 dependencies for `eslint-plugin-import`](https://npmgraph.js.org/?q=eslint-plugin-import)
+- `eslint-plugin-import` uses `tsconfig-paths` + `typescript` itself to load `tsconfig`s while we use the single `get-tsconfig` instead, which is much faster and cleaner
path: README.md
user: login: JounQin
body: > Prove it! Show me the data! 😄

https://github.com/privatenumber/get-tsconfig#features

I can't say for 3rd part libraries. And I'm not interested to prove it because it may be hard as you said.

Similar package: https://github.com/dominikg/tsconfck with benchmark https://github.com/dominikg/tsconfck/blob/main/docs/benchmark.md

And `get-tsconfig` starts because `tsconfck` doesn't have sync API: https://github.com/dominikg/tsconfck/issues/31#issuecomment-1011399496, see also https://github.com/dominikg/tsconfck/issues/183

cc @privatenumber 
created_at: 2025-05-20T14:53:23Z
author_association: MEMBER
diff_hunk: @@ -50,6 +54,35 @@ This plugin intends to support linting of ES2015+ (ES6+) import/export syntax, a
 - [Changelog](#changelog)
 - [License](#license)
 
+## Why
+
+Many issues cannot be fixed easily without API changes. For example, see:
+
+- <https://github.com/import-js/eslint-plugin-import/issues/1479>
+- <https://github.com/import-js/eslint-plugin-import/issues/2108>
+- <https://github.com/import-js/eslint-plugin-import/issues/2111>
+
+[`eslint-plugin-import`] refused to accept BREAKING CHANGES for these issues, so we had to fork it.
+
+[`eslint-plugin-import`] now claims in <https://github.com/un-ts/eslint-plugin-import-x/issues/170> that it will accept BREAKING CHANGES. However, still nothing is happening: <https://github.com/import-js/eslint-plugin-import/pull/3091>.
+
+[`eslint-plugin-import`] refuses to support the `exports` feature, and the maintainer even locked the feature request issue <https://github.com/import-js/eslint-plugin-import/issues/1810> to prevent future discussion. In the meantime, `eslint-plugin-import-x` now provides first-party support for the `exports` feature <https://github.com/un-ts/eslint-plugin-import-x/pull/209>, which will become the default in the next major version (v5).
+
+We haven't resolved all the issues yet, but we are working on them, which could happen in the next major version (v5): <https://github.com/un-ts/eslint-plugin-import-x/issues/235>.
+
+## Differences
+
+So what are the differences from `eslint-plugin-import` exactly?
+
+- we target [Node `^18.18.0 || ^20.9.0 || >=21.1.0`](https://github.com/un-ts/eslint-plugin-import-x/blob/8b2d6d3b612eb57fb68c3fddec25b02fc622df7c/package.json#L12) + [ESLint `^8.57.0 || ^9.0.0`](https://github.com/un-ts/eslint-plugin-import-x/blob/8b2d6d3b612eb57fb68c3fddec25b02fc622df7c/package.json#L71), while `eslint-plugin-import` targets [Node `>=4`](https://github.com/import-js/eslint-plugin-import/blob/da5f6ec13160cb288338db0c2a00c34b2d932f0d/package.json#L6) and [ESLint `^2 || ^3 || ^4 || ^5 || ^6 || ^7.2.0 || ^8 || ^9`](https://github.com/import-js/eslint-plugin-import/blob/da5f6ec13160cb288338db0c2a00c34b2d932f0d/package.json#L115C16-L115C64)
+- we don't depend on old and outdated dependencies, so [we have 49 dependencies](https://npmgraph.js.org/?q=eslint-plugin-import-x) compared to [117 dependencies for `eslint-plugin-import`](https://npmgraph.js.org/?q=eslint-plugin-import)
+- `eslint-plugin-import` uses `tsconfig-paths` + `typescript` itself to load `tsconfig`s while we use the single `get-tsconfig` instead, which is much faster and cleaner
path: README.md
user: login: JounQin
body: Because we're cleaning the ecosystem? https://e18e.dev/guide/cleanup.html
created_at: 2025-05-20T15:03:24Z
author_association: MEMBER
diff_hunk: @@ -50,6 +54,35 @@ This plugin intends to support linting of ES2015+ (ES6+) import/export syntax, a
 - [Changelog](#changelog)
 - [License](#license)
 
+## Why
+
+Many issues cannot be fixed easily without API changes. For example, see:
+
+- <https://github.com/import-js/eslint-plugin-import/issues/1479>
+- <https://github.com/import-js/eslint-plugin-import/issues/2108>
+- <https://github.com/import-js/eslint-plugin-import/issues/2111>
+
+[`eslint-plugin-import`] refused to accept BREAKING CHANGES for these issues, so we had to fork it.
+
+[`eslint-plugin-import`] now claims in <https://github.com/un-ts/eslint-plugin-import-x/issues/170> that it will accept BREAKING CHANGES. However, still nothing is happening: <https://github.com/import-js/eslint-plugin-import/pull/3091>.
+
+[`eslint-plugin-import`] refuses to support the `exports` feature, and the maintainer even locked the feature request issue <https://github.com/import-js/eslint-plugin-import/issues/1810> to prevent future discussion. In the meantime, `eslint-plugin-import-x` now provides first-party support for the `exports` feature <https://github.com/un-ts/eslint-plugin-import-x/pull/209>, which will become the default in the next major version (v5).
+
+We haven't resolved all the issues yet, but we are working on them, which could happen in the next major version (v5): <https://github.com/un-ts/eslint-plugin-import-x/issues/235>.
+
+## Differences
+
+So what are the differences from `eslint-plugin-import` exactly?
+
+- we target [Node `^18.18.0 || ^20.9.0 || >=21.1.0`](https://github.com/un-ts/eslint-plugin-import-x/blob/8b2d6d3b612eb57fb68c3fddec25b02fc622df7c/package.json#L12) + [ESLint `^8.57.0 || ^9.0.0`](https://github.com/un-ts/eslint-plugin-import-x/blob/8b2d6d3b612eb57fb68c3fddec25b02fc622df7c/package.json#L71), while `eslint-plugin-import` targets [Node `>=4`](https://github.com/import-js/eslint-plugin-import/blob/da5f6ec13160cb288338db0c2a00c34b2d932f0d/package.json#L6) and [ESLint `^2 || ^3 || ^4 || ^5 || ^6 || ^7.2.0 || ^8 || ^9`](https://github.com/import-js/eslint-plugin-import/blob/da5f6ec13160cb288338db0c2a00c34b2d932f0d/package.json#L115C16-L115C64)
+- we don't depend on old and outdated dependencies, so [we have 49 dependencies](https://npmgraph.js.org/?q=eslint-plugin-import-x) compared to [117 dependencies for `eslint-plugin-import`](https://npmgraph.js.org/?q=eslint-plugin-import)
+- `eslint-plugin-import` uses `tsconfig-paths` + `typescript` itself to load `tsconfig`s while we use the single `get-tsconfig` instead, which is much faster and cleaner
+- `eslint-plugin-import` uses [`resolve`] which doesn't support the `exports` field in `package.json` while we build our own rust-based resolver [`unrs-resolver`] instead, which is feature-rich and way more performant.
path: README.md
user: login: JounQin
body: Feel free to PR to replace them.
created_at: 2025-05-20T15:04:04Z
author_association: MEMBER
diff_hunk: @@ -50,6 +54,35 @@ This plugin intends to support linting of ES2015+ (ES6+) import/export syntax, a
 - [Changelog](#changelog)
 - [License](#license)
 
+## Why
+
+Many issues cannot be fixed easily without API changes. For example, see:
+
+- <https://github.com/import-js/eslint-plugin-import/issues/1479>
+- <https://github.com/import-js/eslint-plugin-import/issues/2108>
+- <https://github.com/import-js/eslint-plugin-import/issues/2111>
+
+[`eslint-plugin-import`] refused to accept BREAKING CHANGES for these issues, so we had to fork it.
+
+[`eslint-plugin-import`] now claims in <https://github.com/un-ts/eslint-plugin-import-x/issues/170> that it will accept BREAKING CHANGES. However, still nothing is happening: <https://github.com/import-js/eslint-plugin-import/pull/3091>.
path: README.md
user: login: MichaelDeBoey
body: @JoshuaKGoldberg https://discord.com/channels/1227627367204257852/1300975143199309844
created_at: 2025-06-01T23:58:08Z
author_association: NONE
diff_hunk: @@ -50,6 +54,35 @@ This plugin intends to support linting of ES2015+ (ES6+) import/export syntax, a
 - [Changelog](#changelog)
 - [License](#license)
 
+## Why
+
+Many issues cannot be fixed easily without API changes. For example, see:
+
+- <https://github.com/import-js/eslint-plugin-import/issues/1479>
+- <https://github.com/import-js/eslint-plugin-import/issues/2108>
+- <https://github.com/import-js/eslint-plugin-import/issues/2111>
+
+[`eslint-plugin-import`] refused to accept BREAKING CHANGES for these issues, so we had to fork it.
+
+[`eslint-plugin-import`] now claims in <https://github.com/un-ts/eslint-plugin-import-x/issues/170> that it will accept BREAKING CHANGES. However, still nothing is happening: <https://github.com/import-js/eslint-plugin-import/pull/3091>.
+
+[`eslint-plugin-import`] refuses to support the `exports` feature, and the maintainer even locked the feature request issue <https://github.com/import-js/eslint-plugin-import/issues/1810> to prevent future discussion. In the meantime, `eslint-plugin-import-x` now provides first-party support for the `exports` feature <https://github.com/un-ts/eslint-plugin-import-x/pull/209>, which will become the default in the next major version (v5).
path: README.md
user: login: ljharb
body: Difficulty due to constraints that I won't drop is not "refusing" - they have very different connotations in English.
created_at: 2025-06-02T04:02:50Z
author_association: CONTRIBUTOR
diff_hunk: @@ -50,6 +54,35 @@ This plugin intends to support linting of ES2015+ (ES6+) import/export syntax, a
 - [Changelog](#changelog)
 - [License](#license)
 
+## Why
+
+Many issues cannot be fixed easily without API changes. For example, see:
+
+- <https://github.com/import-js/eslint-plugin-import/issues/1479>
+- <https://github.com/import-js/eslint-plugin-import/issues/2108>
+- <https://github.com/import-js/eslint-plugin-import/issues/2111>
+
+[`eslint-plugin-import`] refused to accept BREAKING CHANGES for these issues, so we had to fork it.
+
+[`eslint-plugin-import`] now claims in <https://github.com/un-ts/eslint-plugin-import-x/issues/170> that it will accept BREAKING CHANGES. However, still nothing is happening: <https://github.com/import-js/eslint-plugin-import/pull/3091>.
+
+[`eslint-plugin-import`] refuses to support the `exports` feature, and the maintainer even locked the feature request issue <https://github.com/import-js/eslint-plugin-import/issues/1810> to prevent future discussion. In the meantime, `eslint-plugin-import-x` now provides first-party support for the `exports` feature <https://github.com/un-ts/eslint-plugin-import-x/pull/209>, which will become the default in the next major version (v5).
path: README.md
user: login: JounQin
body: As I said, it's same for end users: refusing breaking changes.
created_at: 2025-06-02T04:06:25Z
author_association: MEMBER
diff_hunk: @@ -50,6 +54,35 @@ This plugin intends to support linting of ES2015+ (ES6+) import/export syntax, a
 - [Changelog](#changelog)
 - [License](#license)
 
+## Why
+
+Many issues cannot be fixed easily without API changes. For example, see:
+
+- <https://github.com/import-js/eslint-plugin-import/issues/1479>
+- <https://github.com/import-js/eslint-plugin-import/issues/2108>
+- <https://github.com/import-js/eslint-plugin-import/issues/2111>
+
+[`eslint-plugin-import`] refused to accept BREAKING CHANGES for these issues, so we had to fork it.
+
+[`eslint-plugin-import`] now claims in <https://github.com/un-ts/eslint-plugin-import-x/issues/170> that it will accept BREAKING CHANGES. However, still nothing is happening: <https://github.com/import-js/eslint-plugin-import/pull/3091>.
+
+[`eslint-plugin-import`] refuses to support the `exports` feature, and the maintainer even locked the feature request issue <https://github.com/import-js/eslint-plugin-import/issues/1810> to prevent future discussion. In the meantime, `eslint-plugin-import-x` now provides first-party support for the `exports` feature <https://github.com/un-ts/eslint-plugin-import-x/pull/209>, which will become the default in the next major version (v5).
path: README.md
user: login: ljharb
body: That's simply not what's happening - there *does not exist* a correct implementation of `exports` resolution that works for an arbitrary node version (not _on_ an arbitrary version, even if it was node 22+ only, but _for_ one). There's no viable option TO refuse.
created_at: 2025-06-02T04:10:12Z
author_association: CONTRIBUTOR
diff_hunk: @@ -50,6 +54,35 @@ This plugin intends to support linting of ES2015+ (ES6+) import/export syntax, a
 - [Changelog](#changelog)
 - [License](#license)
 
+## Why
+
+Many issues cannot be fixed easily without API changes. For example, see:
+
+- <https://github.com/import-js/eslint-plugin-import/issues/1479>
+- <https://github.com/import-js/eslint-plugin-import/issues/2108>
+- <https://github.com/import-js/eslint-plugin-import/issues/2111>
+
+[`eslint-plugin-import`] refused to accept BREAKING CHANGES for these issues, so we had to fork it.
+
+[`eslint-plugin-import`] now claims in <https://github.com/un-ts/eslint-plugin-import-x/issues/170> that it will accept BREAKING CHANGES. However, still nothing is happening: <https://github.com/import-js/eslint-plugin-import/pull/3091>.
+
+[`eslint-plugin-import`] refuses to support the `exports` feature, and the maintainer even locked the feature request issue <https://github.com/import-js/eslint-plugin-import/issues/1810> to prevent future discussion. In the meantime, `eslint-plugin-import-x` now provides first-party support for the `exports` feature <https://github.com/un-ts/eslint-plugin-import-x/pull/209>, which will become the default in the next major version (v5).
path: README.md
user: login: JounQin
body: End users including me don't care about the technology background, we've already been using https://github.com/unrs/unrs-resolver for a long time.
created_at: 2025-06-02T04:14:46Z
author_association: MEMBER
diff_hunk: @@ -50,6 +54,35 @@ This plugin intends to support linting of ES2015+ (ES6+) import/export syntax, a
 - [Changelog](#changelog)
 - [License](#license)
 
+## Why
+
+Many issues cannot be fixed easily without API changes. For example, see:
+
+- <https://github.com/import-js/eslint-plugin-import/issues/1479>
+- <https://github.com/import-js/eslint-plugin-import/issues/2108>
+- <https://github.com/import-js/eslint-plugin-import/issues/2111>
+
+[`eslint-plugin-import`] refused to accept BREAKING CHANGES for these issues, so we had to fork it.
+
+[`eslint-plugin-import`] now claims in <https://github.com/un-ts/eslint-plugin-import-x/issues/170> that it will accept BREAKING CHANGES. However, still nothing is happening: <https://github.com/import-js/eslint-plugin-import/pull/3091>.
+
+[`eslint-plugin-import`] refuses to support the `exports` feature, and the maintainer even locked the feature request issue <https://github.com/import-js/eslint-plugin-import/issues/1810> to prevent future discussion. In the meantime, `eslint-plugin-import-x` now provides first-party support for the `exports` feature <https://github.com/un-ts/eslint-plugin-import-x/pull/209>, which will become the default in the next major version (v5).
path: README.md
user: login: ljharb
body: The "end user" cares about being able to lint using resolution for their target platforms, not just the single node version they're running eslint with. That resolver has the same flaw as every single other alternative, which has been explained.
created_at: 2025-06-02T04:16:38Z
author_association: CONTRIBUTOR
diff_hunk: @@ -50,6 +54,35 @@ This plugin intends to support linting of ES2015+ (ES6+) import/export syntax, a
 - [Changelog](#changelog)
 - [License](#license)
 
+## Why
+
+Many issues cannot be fixed easily without API changes. For example, see:
+
+- <https://github.com/import-js/eslint-plugin-import/issues/1479>
+- <https://github.com/import-js/eslint-plugin-import/issues/2108>
+- <https://github.com/import-js/eslint-plugin-import/issues/2111>
+
+[`eslint-plugin-import`] refused to accept BREAKING CHANGES for these issues, so we had to fork it.
+
+[`eslint-plugin-import`] now claims in <https://github.com/un-ts/eslint-plugin-import-x/issues/170> that it will accept BREAKING CHANGES. However, still nothing is happening: <https://github.com/import-js/eslint-plugin-import/pull/3091>.
+
+[`eslint-plugin-import`] refuses to support the `exports` feature, and the maintainer even locked the feature request issue <https://github.com/import-js/eslint-plugin-import/issues/1810> to prevent future discussion. In the meantime, `eslint-plugin-import-x` now provides first-party support for the `exports` feature <https://github.com/un-ts/eslint-plugin-import-x/pull/209>, which will become the default in the next major version (v5).
path: README.md
user: login: JounQin
body: It's **your** opinion, I don't want to talk about it anymore.
created_at: 2025-06-02T04:18:09Z
author_association: MEMBER
diff_hunk: @@ -50,6 +54,35 @@ This plugin intends to support linting of ES2015+ (ES6+) import/export syntax, a
 - [Changelog](#changelog)
 - [License](#license)
 
+## Why
+
+Many issues cannot be fixed easily without API changes. For example, see:
+
+- <https://github.com/import-js/eslint-plugin-import/issues/1479>
+- <https://github.com/import-js/eslint-plugin-import/issues/2108>
+- <https://github.com/import-js/eslint-plugin-import/issues/2111>
+
+[`eslint-plugin-import`] refused to accept BREAKING CHANGES for these issues, so we had to fork it.
+
+[`eslint-plugin-import`] now claims in <https://github.com/un-ts/eslint-plugin-import-x/issues/170> that it will accept BREAKING CHANGES. However, still nothing is happening: <https://github.com/import-js/eslint-plugin-import/pull/3091>.
+
+[`eslint-plugin-import`] refuses to support the `exports` feature, and the maintainer even locked the feature request issue <https://github.com/import-js/eslint-plugin-import/issues/1810> to prevent future discussion. In the meantime, `eslint-plugin-import-x` now provides first-party support for the `exports` feature <https://github.com/un-ts/eslint-plugin-import-x/pull/209>, which will become the default in the next major version (v5).
path: README.md
user: login: ljharb
body: That's fine, but making slanderous comments about me (eg that i'm "refusing") isn't warranted or intellectually honest. "Clean" is also an opinion, to be clear, not a fact.
created_at: 2025-06-02T04:21:30Z
author_association: CONTRIBUTOR
diff_hunk: @@ -50,6 +54,35 @@ This plugin intends to support linting of ES2015+ (ES6+) import/export syntax, a
 - [Changelog](#changelog)
 - [License](#license)
 
+## Why
+
+Many issues cannot be fixed easily without API changes. For example, see:
+
+- <https://github.com/import-js/eslint-plugin-import/issues/1479>
+- <https://github.com/import-js/eslint-plugin-import/issues/2108>
+- <https://github.com/import-js/eslint-plugin-import/issues/2111>
+
+[`eslint-plugin-import`] refused to accept BREAKING CHANGES for these issues, so we had to fork it.
+
+[`eslint-plugin-import`] now claims in <https://github.com/un-ts/eslint-plugin-import-x/issues/170> that it will accept BREAKING CHANGES. However, still nothing is happening: <https://github.com/import-js/eslint-plugin-import/pull/3091>.
+
+[`eslint-plugin-import`] refuses to support the `exports` feature, and the maintainer even locked the feature request issue <https://github.com/import-js/eslint-plugin-import/issues/1810> to prevent future discussion. In the meantime, `eslint-plugin-import-x` now provides first-party support for the `exports` feature <https://github.com/un-ts/eslint-plugin-import-x/pull/209>, which will become the default in the next major version (v5).
path: README.md
user: login: JounQin
body: > You may help to reconstruct the sentence, it's just our feelings, everyone could have different feelings.

The fact is `exports` is not supported.

> "Clean" is also an opinion, to be clear, not a fact.

It's a fact. :)
created_at: 2025-06-02T04:22:31Z
author_association: MEMBER

PR comments:
user: login: changeset-bot[bot]
created_at: 2025-05-14T16:01:12Z
body: ###  ⚠️  No Changeset found

Latest commit: f74abd60b7a35905ea7ffae4b29e1cb8bb22856e

Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. **If these changes should result in a version bump, you need to add a changeset.**

<details><summary>This PR includes no changesets</summary>

  When changesets are added to this PR, you'll see the packages that this PR includes changesets for and the associated semver types

</details>

[Click here to learn what changesets are, and how to add one](https://github.com/changesets/changesets/blob/main/docs/adding-a-changeset.md).

[Click here if you're a maintainer who wants to add a changeset to this PR](https://github.com/un-ts/eslint-plugin-import-x/new/docs/why?filename=.changeset/yellow-vans-camp.md&value=---%0A%22eslint-plugin-import-x%22%3A%20patch%0A---%0A%0Adocs%3A%20add%20%60why%60%20section%20on%20the%20top%20to%20clarify%0A)


author_association: NONE
user: login: codacy-production[bot]
created_at: 2025-05-14T16:01:13Z
body: ## Coverage summary from Codacy
### [See diff coverage on Codacy](https://app.codacy.com/gh/un-ts/eslint-plugin-import-x/pull-requests/323/coverage?utm_source=github.com&utm_medium=coverageSummary&utm_campaign=coverageSummaryPullRequest)

 | Coverage variation | Diff coverage | 
 | ------------- | ------------- |
 | :white_check_mark: **+0.00%** (target: -1.00%) | :white_check_mark: **∅** |

<details>
<summary>Coverage variation details</summary>

| | Coverable lines | Covered lines | Coverage |
| ------------- | ------------- | ------------- | ------------- |
| Common ancestor commit (8b2d6d3b612eb57fb68c3fddec25b02fc622df7c) | 3574 | 3416 | 95.58% | |
| Head commit (32a6b98d562759f0faa9220d77f0d09add5d5d61) | 3574 (+0) | 3416 (+0) | 95.58% (**+0.00%**) |

**Coverage variation** is the difference between the coverage for the head and common ancestor commits of the pull request branch: `<coverage of head commit> - <coverage of common ancestor commit>`
</details>

<details>
<summary>Diff coverage details</summary>

| | Coverable lines | Covered lines | Diff coverage |
| ------------- | ------------- | ------------- | ------------- |
| Pull request (#323) | 0 | 0 | **∅ (not applicable)** |

**Diff coverage** is the percentage of lines that are covered by tests out of the coverable lines that the pull request added or modified: `<covered lines added or modified>/<coverable lines added or modified> * 100%`
</details>

#### [See your quality gate settings](https://app.codacy.com/gh/un-ts/eslint-plugin-import-x/settings/quality?utm_source=github.com&utm_medium=coverageSummary&utm_campaign=coverageSummaryGates)&nbsp;&nbsp;&nbsp;&nbsp;[Change summary preferences](https://app.codacy.com/gh/un-ts/eslint-plugin-import-x/settings/integrations?utm_source=github.com&utm_medium=coverageSummary&utm_campaign=coverageSummarySettings)

<!-- 108f945d-e553-4918-8ccf-027c6d4acc2c -->
author_association: NONE
user: login: coderabbitai[bot]
created_at: 2025-05-14T16:01:16Z
body: <!-- This is an auto-generated comment: summarize by coderabbit.ai -->
<!-- walkthrough_start -->

## Walkthrough

The changes update the staged linting tool from `@1stg/lint-staged` to `@1stg/nano-staged` in both configuration and dependencies. The README is expanded with a new "Why" section, explaining the rationale for forking from `eslint-plugin-import`, and detailing differences and improvements.

## Changes

| File(s)               | Change Summary                                                                                                      |
|-----------------------|---------------------------------------------------------------------------------------------------------------------|
| .nano-staged.js        | Changed the default export to use `@1stg/nano-staged/tsc` instead of `@1stg/lint-staged/tsc`.                      |
| package.json           | Replaced `@1stg/lint-staged` with `@1stg/nano-staged` in `devDependencies`.                                         |
| README.md              | Added a "Why" section detailing the fork rationale and differences from `eslint-plugin-import`; updated TOC, intro, and references. |

## Assessment against linked issues

| Objective                                                                                         | Addressed | Explanation |
|---------------------------------------------------------------------------------------------------|-----------|-------------|
| Add a "Why" or "Different with eslint-plugin-import" section in the README (#196)                 | ✅        |             |

## Poem

> A nano hop from lint to staged,  
> With README tales now well engaged.  
> Why the fork? The reasons told—  
> Dependencies trimmed, improvements bold.  
> Now code and docs both shine anew,  
> 🐇 Cheers to progress, swift and true!  
>

<!-- walkthrough_end -->

<!-- announcements_start -->

> [!NOTE]
> <details>
> <summary>⚡️ AI Code Reviews for VS Code, Cursor, Windsurf</summary>
> 
> CodeRabbit now has a plugin for VS Code, Cursor and Windsurf. This brings AI code reviews directly in the code editor. Each commit is reviewed immediately, finding bugs before the PR is raised. Seamless context handoff to your AI code agent ensures that you can easily incorporate review feedback.
> Learn more [here](http://coderabbit.ai/ide).
> 
> </details>

---

> [!NOTE]
> <details>
> <summary>⚡️ Faster reviews with caching</summary>
> 
> CodeRabbit now supports caching for code and dependencies, helping speed up reviews. This means quicker feedback, reduced wait times, and a smoother review experience overall. Cached data is encrypted and stored securely. This feature will be automatically enabled for all accounts on May 16th. To opt out, configure `Review - Disable Cache` at either the organization or repository level. If you prefer to disable all data retention across your organization, simply turn off the `Data Retention` setting under your Organization Settings.
> Enjoy the performance boost—your workflow just got faster.
> 
> </details>

<!-- announcements_end -->
<!-- internal state start -->


<!-- DwQgtGAEAqAWCWBnSTIEMB26CuAXA9mAOYCmGJATmriQCaQDG+Ats2bgFyQAOFk+AIwBWJBrngA3EsgEBPRvlqU0AgfFwA6NPEgQAfACgjoCEYDEZyAAUASpETZWaCrKNwSPbABsvkCiQBHbGlcSHFcLzpIACJafAZELjRaegADAHdYWVT7UXF8LAKw2A8CbjD8Ri9neAAzWWjIdLRkBwFmdRp6OWKPbERKSAApfGwMAEV4LBbPHz9A4MRQjEcBQYBmACZ1jRgS6ztk2mQ0SHJ0mIB1LMaBsXgi6l7INaIpjCmiflrn1JsAUQAggARACy/w0zFoOQIkBIAA9uNUps8qPkMGhIpBavg+DiKABrT7PXHwN4Y3ypaReKa4MBI7DksDwZjcXG4HKYeiwhBEWA0vmhAkkeS0Oq1ShkBjSFBYKmIGkYOkMpkstkUOnw1K7OCoI7qB7TFnIWEMaoUOryXD7bjYChsgboDD0Zj4cQSaiG77PXj4ERiHX7aAqLH4H4AYQKNCVyBR1o8fyBYIhUJyeq8iEq2G4tGoUVhUzN2CUz3OuXuBQ0RgAktMUgairC4gxHOxPUU1RR8FI2DGADTPWyQbO5mjIJRSLz4bi90IEfCKr49fxItAMYnxyBKbhkJQYBjyVIAAQAjEsiAB6RV0pZoUjQprqWCQY9n3CXjEYQi3+9puXcNcCTvEgNCETMME5Z1GFgTByS+TcEXVUIUW1T9v1wYDaFAxBOQYJgKDFDAiC8WRA2kDwGBgoiZWcDxaV3fNKk7btSn2edF1yXBsyrAx3AOeYJX8fcZTNfBEGJJAHA8MwTwATgANidbk72QfpKGQI9kgtTBiHgZQCXwdJECJAcjzWDBmDwzAMFMkZEFgbA0AAaQAcQXWg1goIgBy5SAjwAZWwAkgMubFcXmCQ9IucKWnE29hLInBrXCr8x16eRaLON10DOT0pEgf4iJpez7B3NBhT4Xz0hILwmDYZASi8coC1ZLt8s3dJcUIr4w2eI4ojudFEttOZ/CCEIUAasSun4LBNxXMT1FxeRqVpekvEZKZmVZdkwHhJTJvQD14GqAQsSeWBcFwbhEgvC83mtbABA0OqLzGMBcEQC9VqVdbNowbakL2i8Rq8C8th2cxLEjVh2FaRxmGcVxeP2AoSIUWGlVmn1vF8MbFmQ5Bai7Zg+rwWBcQHEYxkmGymgp9AUn8RABg08zLIYazdmpiYUUQ5nWcgIg0XUYsPF8/GQhNSo1llfE2HoAppXQOYHCIUglkNBq0HytYyEgRGS0zYonnjeROembgkQyuZKNgmUCFIeM+BRAo+hzPMyP8dBva/fhnYx2dkHCsVEBbFmtfmfClEVuaEGQUH5nGpYeP0YxwCgXdvTQPBCFIcg0SiOrZy4Xh+GEPJJBlHomCUKhVHULQdDTkwoF1WMTmmXPiDIZQZuL9guCoC4HCcFwXnNxRlAbzRtF0MBDHT0wDA0NCwB/OhsI4Axol3gwLEgQFqx7gu83oUfEfH3q7eoxA3H2RD2XsDCaFnWVflXzB0Mw7CclqE6PDNGQDfe8FQUA7Q1M8JQtQc5eFCI/SBxMWA5TFLUQS7ADaKG8CBaw/hIqjAVLIAc6h5hgAQTNTc0DYHwMRE/JBpNNyuloNgl8p5zxXjWhvWgF5PoMG1IfWoNA+CbhASQYhyxDKkPISafYVDvA0KQtiEmrC3wfi/uvDC94eFh34QAOUqG6EofApxvAYPwPgtdAEzCYXUPSWEjBQ0PnAvukdYSUNEOadsGBg4/HIVEcKtozrwDMewA00gjBQH0dBe20stweOcF4nxcJaEan8XwQJNIQlKjCYgAA3LNdGm5Mx2mVkwlhvV3EwPkckxRQDonUXoChT+X4NE/zAtqHee8DAQDAEYAEIJwSQloNvXe0R96WCPifPuA0EZI29KIu+KMPD9OTEMpoMwyBUWlPQdIT4zgkBHpXAoyBojXAaAdaIwJxSSmEogRosJELIjjh4EWBRMQeDWAgKC+IiRERfD9ZUG1VQQI5AdHkZJ+QQtCKHcQ+50RE2UY3PYHhTk3HLOiOJGETqqQwMzBcUhGks0WO/TcpJySYh4ECuMMFQj43gP4bo/hyrEkBFYas9SNb02Cc+aq3t/C1DUrQAc65YVfEQDudc/8zGSWCAdROksliQEVASRAuxqyhExMbVKDtUYWnJb4FUUwADkyB+X9ApbCBwVsn6bipCkz6f89JeEaVgACDAgKkGwo8KCm4pzuuJL1fw1QZoSmoHaF5CwpYDkyAA/5Co1qGoBmqXaWoeBtXgEoIm9Klj0mcLgeQVrFH4mKKgUNXFvargwOQegMw5FwJJfscg8JQiIyEOFKQFBxKVmRTEK5aCbnSjueir0ZBWyF2QMKSeSoqBLESGEZwTtiTnEGPopQ2FIAdq7d4yAAAKAAeieAAHBoI9GgAAMA492bDPRoWS56Bx6AALybBPCe89ABKA6/x/IABlaQbvUpHfdx6ACsAB2e9kA913pvWez9m7+gkj1VMTEJqXhdmSIMQt7J8kwUin8iUvK4k7mdFKPSyAd0ABZZIbtVZAE8J4wPvvySuao64/mpF4QUf+RBc3WhwgdTjsgdxhwtNwUFuzrQvidh9MO3GyR/3CjApYgxfJmhIJgQYXGMA8aVfgZInx8n9GJKcGw/Q6QCBaFEPFXgO0vjGJ2sANmO1/hU8kb0qRnMkBhJUbDkDbXSMdTVGtUFmL5R3BQeWmBpT5N8vZGofzTjiSKhGzMtnBhTHisrHodbQjFs5pREzUE2CungAALy8bsQE9Z0SYhIgOTcKzwSM2ODlbVJs5z7GKqEXqqD0G3INmgeQwtJG+ULBtTN+yLj8oHTKYtm5+r0G3Axfc5G5Vdn9J9HijjATONedutxsj4n7aSX4xW6SnqZLhNk8Q4SDD6PIFWUZETl5uo9SBMCBQRl7wPpM/O0zz6zKvj8BZ98PAThqtON+y3SP7nkNENh74OG/S4Y0TdXpoh7so+e29jQ6n+FdASg6rG1xREk8+BHqiLxr1RwBztGO903tfSeRo1KEwTmBCQEje51zSByINL0FT9ipDe8BL1EFsQAN2FEwxgwFlgJhzztb4VRPwHE8gXlHhDYgQceMpxQjElgPcWaBJ8LvRnfMZ4IJWTwjkaMA9nXz3ukLyXpnKCvUc4ECmYXegA8lRDzQCPIH8ga5T3rmoWezcXet0DuoAA+hmxAce8FRToHH28kC04GBj1sNA8kBCyUPbQED8lNhgZA7JWoZ6YFoFkpsa9tAwNgar7QM9skjggeL7QeSJ556GBzyBtAZ6z2HrA9X2o6x1jyXWGe6jYGBDT4EIekg8kQPrBPGv2o4GwNKBA9sU4LcM6QDPbQTYh7J9rkLxPw9J+SAnnWIegQYHL/d9H9ek8JAz3P4/5R9YPxD8QDoAkCbAMCUZgYz6UYMAnhrCbCUaqDrBgYMDrBgFnqMayRP4gYkDrCWYCCbCYECD/7R5H6bAeQl4kCD7yTT6wH37L60CF7L4MBP7yS1DoFL5gYni1ApC0Anhl597Z5H5T5npoDIGqC1AMCHr0FoC1AMabCcGIG1CbAr64FrggHrCMGgEkA0YAFQC1BgaUYqDd5npP7CEV5nqYFoDN4wIkBwGbCyR36MGP64Fn5kF8H8GAHFzx6J7J4kCRQHJp5Zz6BAA= -->

<!-- internal state end -->
<!-- tips_start -->

---

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.

<details>
<summary>❤️ Share</summary>

- [X](https://twitter.com/intent/tweet?text=I%20just%20used%20%40coderabbitai%20for%20my%20code%20review%2C%20and%20it%27s%20fantastic%21%20It%27s%20free%20for%20OSS%20and%20offers%20a%20free%20trial%20for%20the%20proprietary%20code.%20Check%20it%20out%3A&url=https%3A//coderabbit.ai)
- [Mastodon](https://mastodon.social/share?text=I%20just%20used%20%40coderabbitai%20for%20my%20code%20review%2C%20and%20it%27s%20fantastic%21%20It%27s%20free%20for%20OSS%20and%20offers%20a%20free%20trial%20for%20the%20proprietary%20code.%20Check%20it%20out%3A%20https%3A%2F%2Fcoderabbit.ai)
- [Reddit](https://www.reddit.com/submit?title=Great%20tool%20for%20code%20review%20-%20CodeRabbit&text=I%20just%20used%20CodeRabbit%20for%20my%20code%20review%2C%20and%20it%27s%20fantastic%21%20It%27s%20free%20for%20OSS%20and%20offers%20a%20free%20trial%20for%20proprietary%20code.%20Check%20it%20out%3A%20https%3A//coderabbit.ai)
- [LinkedIn](https://www.linkedin.com/sharing/share-offsite/?url=https%3A%2F%2Fcoderabbit.ai&mini=true&title=Great%20tool%20for%20code%20review%20-%20CodeRabbit&summary=I%20just%20used%20CodeRabbit%20for%20my%20code%20review%2C%20and%20it%27s%20fantastic%21%20It%27s%20free%20for%20OSS%20and%20offers%20a%20free%20trial%20for%20proprietary%20code)

</details>

<details>
<summary>🪧 Tips</summary>

### Chat

There are 3 ways to chat with [CodeRabbit](https://coderabbit.ai?utm_source=oss&utm_medium=github&utm_campaign=un-ts/eslint-plugin-import-x&utm_content=323):

- Review comments: Directly reply to a review comment made by CodeRabbit. Example:
  - `I pushed a fix in commit <commit_id>, please review it.`
  - `Explain this complex logic.`
  - `Open a follow-up GitHub issue for this discussion.`
- Files and specific lines of code (under the "Files changed" tab): Tag `@coderabbitai` in a new review comment at the desired location with your query. Examples:
  - `@coderabbitai explain this code block.`
  -	`@coderabbitai modularize this function.`
- PR comments: Tag `@coderabbitai` in a new PR comment to ask questions about the PR branch. For the best results, please provide a very specific query, as very limited context is provided in this mode. Examples:
  - `@coderabbitai gather interesting stats about this repository and render them as a table. Additionally, render a pie chart showing the language distribution in the codebase.`
  - `@coderabbitai read src/utils.ts and explain its main purpose.`
  - `@coderabbitai read the files in the src/scheduler package and generate a class diagram using mermaid and a README in the markdown format.`
  - `@coderabbitai help me debug CodeRabbit configuration file.`

### Support

Need help? Create a ticket on our [support page](https://www.coderabbit.ai/contact-us/support) 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)

- `@coderabbitai pause` to pause the reviews on a PR.
- `@coderabbitai resume` to resume the paused reviews.
- `@coderabbitai review` to trigger an incremental review. This is useful when automatic reviews are disabled for the repository.
- `@coderabbitai full review` to do a full review from scratch and review all the files again.
- `@coderabbitai summary` to regenerate the summary of the PR.
- `@coderabbitai generate docstrings` to [generate docstrings](https://docs.coderabbit.ai/finishing-touches/docstrings) for this PR.
- `@coderabbitai generate sequence diagram` to generate a sequence diagram of the changes in this PR.
- `@coderabbitai resolve` resolve all the CodeRabbit review comments.
- `@coderabbitai configuration` to show the current CodeRabbit configuration for the repository.
- `@coderabbitai help` to get help.

### Other keywords and placeholders

- Add `@coderabbitai ignore` anywhere in the PR description to prevent this PR from being reviewed.
- Add `@coderabbitai summary` to generate the high-level summary at a specific location in the PR description.
- Add `@coderabbitai` anywhere in the PR title to generate the title automatically.

### CodeRabbit Configuration File (`.coderabbit.yaml`)

- You can programmatically configure CodeRabbit by adding a `.coderabbit.yaml` file to the root of your repository.
- Please see the [configuration documentation](https://docs.coderabbit.ai/guides/configure-coderabbit) for more information.
- If your editor has YAML language server enabled, you can add the path at the top of this file to enable auto-completion and validation: `# yaml-language-server: $schema=https://coderabbit.ai/integrations/schema.v2.json`

### Documentation and Community

- Visit our [Documentation](https://docs.coderabbit.ai) for detailed information on how to use CodeRabbit.
- Join our [Discord Community](http://discord.gg/coderabbit) to get help, request features, and share feedback.
- Follow us on [X/Twitter](https://twitter.com/coderabbitai) for updates and announcements.

</details>

<!-- tips_end -->
author_association: CONTRIBUTOR
user: login: codesandbox-ci[bot]
created_at: 2025-05-14T16:01:36Z
body: This pull request is automatically built and testable in [CodeSandbox](https://codesandbox.io).

  To see build info of the built libraries, click [here](https://ci.codesandbox.io/status/un-ts/eslint-plugin-import-x/pr/323/builds/616619) or the icon next to each commit SHA.
author_association: NONE
user: login: petercat-assistant[bot]
created_at: 2025-05-14T16:01:39Z
body: ### Walkthrough
This pull request introduces a new `Why` section at the top of the README to clarify the reasons behind forking `eslint-plugin-import` and the differences between the two plugins. Additionally, it updates dependencies from `@1stg/lint-staged` to `@1stg/nano-staged` in various configuration files.

### Changes
| Files | Summary |
|-------|---------|
| .nano-staged.js, package.json, yarn.lock | Updated dependency from `@1stg/lint-staged` to `@1stg/nano-staged`. |
| README.md | Added a new `Why` section explaining the rationale behind the fork and differences from `eslint-plugin-import`. |
author_association: NONE
user: login: codecov[bot]
created_at: 2025-05-14T16:01:40Z
body: ## [Codecov](https://app.codecov.io/gh/un-ts/eslint-plugin-import-x/pull/323?dropdown=coverage&src=pr&el=h1&utm_medium=referral&utm_source=github&utm_content=comment&utm_campaign=pr+comments&utm_term=un-ts) Report
All modified and coverable lines are covered by tests :white_check_mark:
> Project coverage is 96.02%. Comparing base [(`8b2d6d3`)](https://app.codecov.io/gh/un-ts/eslint-plugin-import-x/commit/8b2d6d3b612eb57fb68c3fddec25b02fc622df7c?dropdown=coverage&el=desc&utm_medium=referral&utm_source=github&utm_content=comment&utm_campaign=pr+comments&utm_term=un-ts) to head [(`f74abd6`)](https://app.codecov.io/gh/un-ts/eslint-plugin-import-x/commit/f74abd60b7a35905ea7ffae4b29e1cb8bb22856e?dropdown=coverage&el=desc&utm_medium=referral&utm_source=github&utm_content=comment&utm_campaign=pr+comments&utm_term=un-ts).
> Report is 1 commits behind head on master.

<details><summary>Additional details and impacted files</summary>


```diff
@@           Coverage Diff           @@
##           master     #323   +/-   ##
=======================================
  Coverage   96.02%   96.02%           
=======================================
  Files          92       92           
  Lines        4758     4758           
  Branches     1768     1789   +21     
=======================================
  Hits         4569     4569           
  Misses        188      188           
  Partials        1        1           
```

</details>

[:umbrella: View full report in Codecov by Sentry](https://app.codecov.io/gh/un-ts/eslint-plugin-import-x/pull/323?dropdown=coverage&src=pr&el=continue&utm_medium=referral&utm_source=github&utm_content=comment&utm_campaign=pr+comments&utm_term=un-ts).   
:loudspeaker: Have feedback on the report? [Share it here](https://about.codecov.io/codecov-pr-comment-feedback/?utm_medium=referral&utm_source=github&utm_content=comment&utm_campaign=pr+comments&utm_term=un-ts).

<details><summary> :rocket: New features to boost your workflow: </summary>

- :snowflake: [Test Analytics](https://docs.codecov.com/docs/test-analytics): Detect flaky tests, report on failures, and find test suite problems.
- :package: [JS Bundle Analysis](https://docs.codecov.com/docs/javascript-bundle-analysis): Save yourself from yourself by tracking and limiting bundle sizes in JS merges.
</details>
author_association: NONE
user: login: socket-security[bot]
created_at: 2025-05-14T16:01:41Z
body: **Review the following changes in direct dependencies.** Learn more about [Socket for GitHub](https://socket.dev?utm_medium=gh).

<table>
<thead>
<tr>
<th>Diff</th>
<th width="200px">Package</th>
<th align="left" width="100px">Supply Chain<br/>Security</th>
<th align="left" width="100px">Vulnerability</th>
<th align="left" width="100px">Quality</th>
<th align="left" width="100px">Maintenance</th>
<th align="left" width="100px">License</th>
</tr>
</thead>
<tbody>
<tr><td align="center"><a href="https://socket.dev/dashboard/org/un-ts/diff/d0343726-914d-435e-8cef-d00f28ea59c9/00c60a45-9b9d-42fd-949e-8f2d162abeca?tab=dependencies&dependency_item_key=22891241545"><img src="https://github-app-statics.socket.dev/diff-added.svg" title="Added" alt="Added" width="20" height="20"></a></td><td><a href="https://socket.dev/dashboard/org/un-ts/diff/d0343726-914d-435e-8cef-d00f28ea59c9/00c60a45-9b9d-42fd-949e-8f2d162abeca?tab=dependencies&dependency_item_key=22891241545">@​1stg/​nano-staged@​0.1.1</a></td><td align="left"><a href="https://socket.dev/dashboard/org/un-ts/diff/d0343726-914d-435e-8cef-d00f28ea59c9/00c60a45-9b9d-42fd-949e-8f2d162abeca?tab=dependencies&dependency_item_key=22891241545"><img src="https://github-app-statics.socket.dev/score-71.svg" title="Supply Chain Security" width="40" height="40" alt="71"></a></td><td align="left"><a href="https://socket.dev/dashboard/org/un-ts/diff/d0343726-914d-435e-8cef-d00f28ea59c9/00c60a45-9b9d-42fd-949e-8f2d162abeca?tab=dependencies&dependency_item_key=22891241545"><img src="https://github-app-statics.socket.dev/score-100.svg" title="Vulnerability" width="40" height="40" alt="100"></a></td><td align="left"><a href="https://socket.dev/dashboard/org/un-ts/diff/d0343726-914d-435e-8cef-d00f28ea59c9/00c60a45-9b9d-42fd-949e-8f2d162abeca?tab=dependencies&dependency_item_key=22891241545"><img src="https://github-app-statics.socket.dev/score-72.svg" title="Quality" width="40" height="40" alt="72"></a></td><td align="left"><a href="https://socket.dev/dashboard/org/un-ts/diff/d0343726-914d-435e-8cef-d00f28ea59c9/00c60a45-9b9d-42fd-949e-8f2d162abeca?tab=dependencies&dependency_item_key=22891241545"><img src="https://github-app-statics.socket.dev/score-87.svg" title="Maintenance" width="40" height="40" alt="87"></a></td><td align="left"><a href="https://socket.dev/dashboard/org/un-ts/diff/d0343726-914d-435e-8cef-d00f28ea59c9/00c60a45-9b9d-42fd-949e-8f2d162abeca?tab=dependencies&dependency_item_key=22891241545"><img src="https://github-app-statics.socket.dev/score-100.svg" title="License" width="40" height="40" alt="100"></a></td></tr>
<tr><td align="center"><a href="https://socket.dev/dashboard/org/un-ts/diff/d0343726-914d-435e-8cef-d00f28ea59c9/00c60a45-9b9d-42fd-949e-8f2d162abeca?tab=dependencies&dependency_item_key=26228335207"><img src="https://github-app-statics.socket.dev/diff-updated.svg" title="Updated" alt="Updated" width="20" height="20"></a></td><td><a href="https://socket.dev/dashboard/org/un-ts/diff/d0343726-914d-435e-8cef-d00f28ea59c9/00c60a45-9b9d-42fd-949e-8f2d162abeca?tab=dependencies&dependency_item_key=26228335207">@​1stg/​prettier-config@​5.1.4 ⏵ 5.2.0</a></td><td align="left"><a href="https://socket.dev/dashboard/org/un-ts/diff/d0343726-914d-435e-8cef-d00f28ea59c9/00c60a45-9b9d-42fd-949e-8f2d162abeca?tab=dependencies&dependency_item_key=26228335207"><img src="https://github-app-statics.socket.dev/score-92.svg" title="Supply Chain Security" width="40" height="40" alt="92"></a> <sup>-1</sup></td><td align="left"><a href="https://socket.dev/dashboard/org/un-ts/diff/d0343726-914d-435e-8cef-d00f28ea59c9/00c60a45-9b9d-42fd-949e-8f2d162abeca?tab=dependencies&dependency_item_key=26228335207"><img src="https://github-app-statics.socket.dev/score-100.svg" title="Vulnerability" width="40" height="40" alt="100"></a></td><td align="left"><a href="https://socket.dev/dashboard/org/un-ts/diff/d0343726-914d-435e-8cef-d00f28ea59c9/00c60a45-9b9d-42fd-949e-8f2d162abeca?tab=dependencies&dependency_item_key=26228335207"><img src="https://github-app-statics.socket.dev/score-75.svg" title="Quality" width="40" height="40" alt="75"></a> <sup>+1</sup></td><td align="left"><a href="https://socket.dev/dashboard/org/un-ts/diff/d0343726-914d-435e-8cef-d00f28ea59c9/00c60a45-9b9d-42fd-949e-8f2d162abeca?tab=dependencies&dependency_item_key=26228335207"><img src="https://github-app-statics.socket.dev/score-94.svg" title="Maintenance" width="40" height="40" alt="94"></a></td><td align="left"><a href="https://socket.dev/dashboard/org/un-ts/diff/d0343726-914d-435e-8cef-d00f28ea59c9/00c60a45-9b9d-42fd-949e-8f2d162abeca?tab=dependencies&dependency_item_key=26228335207"><img src="https://github-app-statics.socket.dev/score-100.svg" title="License" width="40" height="40" alt="100"></a></td></tr>
</tbody>
</table>

[View full report](https://socket.dev/dashboard/org/un-ts/diff/d0343726-914d-435e-8cef-d00f28ea59c9/00c60a45-9b9d-42fd-949e-8f2d162abeca?tab=dependencies)

<!-- overview-comment -->
author_association: NONE
user: login: codacy-production[bot]
created_at: 2025-05-14T16:01:57Z
body: ## Coverage summary from Codacy
### [See diff coverage on Codacy](https://app.codacy.com/gh/un-ts/eslint-plugin-import-x/pull-requests/323/coverage?utm_source=github.com&utm_medium=coverageSummary&utm_campaign=coverageSummaryPullRequest)

 | Coverage variation | Diff coverage | 
 | ------------- | ------------- |
 | :white_check_mark: **+0.00%** (target: -1.00%) | :white_check_mark: **∅** |

<details>
<summary>Coverage variation details</summary>

| | Coverable lines | Covered lines | Coverage |
| ------------- | ------------- | ------------- | ------------- |
| Common ancestor commit (8b2d6d3b612eb57fb68c3fddec25b02fc622df7c) | 3574 | 3416 | 95.58% | |
| Head commit (f74abd60b7a35905ea7ffae4b29e1cb8bb22856e) | 3574 (+0) | 3416 (+0) | 95.58% (**+0.00%**) |

**Coverage variation** is the difference between the coverage for the head and common ancestor commits of the pull request branch: `<coverage of head commit> - <coverage of common ancestor commit>`
</details>

<details>
<summary>Diff coverage details</summary>

| | Coverable lines | Covered lines | Diff coverage |
| ------------- | ------------- | ------------- | ------------- |
| Pull request (#323) | 0 | 0 | **∅ (not applicable)** |

**Diff coverage** is the percentage of lines that are covered by tests out of the coverable lines that the pull request added or modified: `<covered lines added or modified>/<coverable lines added or modified> * 100%`
</details>

#### [See your quality gate settings](https://app.codacy.com/gh/un-ts/eslint-plugin-import-x/settings/quality?utm_source=github.com&utm_medium=coverageSummary&utm_campaign=coverageSummaryGates)&nbsp;&nbsp;&nbsp;&nbsp;[Change summary preferences](https://app.codacy.com/gh/un-ts/eslint-plugin-import-x/settings/integrations?utm_source=github.com&utm_medium=coverageSummary&utm_campaign=coverageSummarySettings)

<!-- 108f945d-e553-4918-8ccf-027c6d4acc2c -->
author_association: NONE
user: login: pkg-pr-new[bot]
created_at: 2025-05-14T16:01:57Z
body: 
[Open in StackBlitz](https://pkg.pr.new/template/bd18a3ba-26fd-49b6-8fdf-3148af9c0663)


```
npm i https://pkg.pr.new/eslint-plugin-import-x@323
```


_commit: <a href="https://github.com/un-ts/eslint-plugin-import-x/runs/42269692058"><code>f74abd6</code></a>_

author_association: NONE
user: login: coderabbitai[bot]
created_at: 2025-05-14T16:33:31Z
body: > [!CAUTION]
> No docstrings were generated.
author_association: CONTRIBUTOR
user: login: JounQin
created_at: 2025-05-15T03:18:18Z
body: @benmccann Great thanks! Just let me know when all suggestions are made so that I can apply them once together.
author_association: MEMBER
user: login: sonarqubecloud[bot]
created_at: 2025-05-15T08:20:34Z
body: ## [![Quality Gate Passed](https://sonarsource.github.io/sonarcloud-github-static-resources/v2/checks/QualityGateBadge/qg-passed-20px.png 'Quality Gate Passed')](https://sonarcloud.io/dashboard?id=un-ts_eslint-plugin-import-x&pullRequest=323) **Quality Gate passed**  
Issues  
![](https://sonarsource.github.io/sonarcloud-github-static-resources/v2/common/passed-16px.png '') [0 New issues](https://sonarcloud.io/project/issues?id=un-ts_eslint-plugin-import-x&pullRequest=323&issueStatuses=OPEN,CONFIRMED&sinceLeakPeriod=true)  
![](https://sonarsource.github.io/sonarcloud-github-static-resources/v2/common/accepted-16px.png '') [0 Accepted issues](https://sonarcloud.io/project/issues?id=un-ts_eslint-plugin-import-x&pullRequest=323&issueStatuses=ACCEPTED)

Measures  
![](https://sonarsource.github.io/sonarcloud-github-static-resources/v2/common/passed-16px.png '') [0 Security Hotspots](https://sonarcloud.io/project/security_hotspots?id=un-ts_eslint-plugin-import-x&pullRequest=323&issueStatuses=OPEN,CONFIRMED&sinceLeakPeriod=true)  
![](https://sonarsource.github.io/sonarcloud-github-static-resources/v2/common/passed-16px.png '') [0.0% Coverage on New Code](https://sonarcloud.io/component_measures?id=un-ts_eslint-plugin-import-x&pullRequest=323&metric=new_coverage&view=list)  
![](https://sonarsource.github.io/sonarcloud-github-static-resources/v2/common/passed-16px.png '') [0.0% Duplication on New Code](https://sonarcloud.io/component_measures?id=un-ts_eslint-plugin-import-x&pullRequest=323&metric=new_duplicated_lines_density&view=list)  
  
[See analysis details on SonarQube Cloud](https://sonarcloud.io/dashboard?id=un-ts_eslint-plugin-import-x&pullRequest=323)


author_association: NONE
user: login: JounQin
created_at: 2025-05-15T08:30:16Z
body: Maybe @benmccann want to take another look again since @SukkaW reviews and suggestions.
author_association: MEMBER
user: login: JoshuaKGoldberg
created_at: 2025-05-20T17:44:26Z
body: @JounQin sorry if I wasn't clear on this in https://github.com/un-ts/eslint-plugin-import-x/pull/323#pullrequestreview-2854093912: I'm not asking you to justify them here. For a lot of the commented questions I actually know the answers already 🙂. I'm trying to post the questions that users are asking & I think the README.md needs to answer to be convincing.

For example, https://github.com/un-ts/eslint-plugin-import-x/pull/323#discussion_r2098099438:

> > cleaner
>
> Why would an end-user care about this?

I'm not trying to ask you to answer that here. _I'm_ in favor of the smaller dependencies, the general e18e guide, etc. What I'm trying to convey is: just stating something as "faster and cleaner" _without any specifics_ is not convincing. Giving specifics (what we're talking about in https://github.com/e18e/e18e/issues/66) would be more convincing.
author_association: CONTRIBUTOR
user: login: JounQin
created_at: 2025-05-20T17:49:39Z
body: > I'm not asking you to justify them here. For a lot of the commented questions I actually know the answers already 🙂. I'm trying to post the questions that users are asking & I think the README.md needs to answer to be convincing.

Thanks for clarification @JoshuaKGoldberg! Would you like to raise a PR with what you're proposing? In case that you've actually known the answers already.

---

Actually I even didn't notice https://github.com/un-ts/eslint-plugin-import-x/pull/323#pullrequestreview-2854093912, poor GitHub review experience.

author_association: MEMBER
user: login: JoshuaKGoldberg
created_at: 2025-05-20T17:54:17Z
body: Oh yay! I'm glad - without that context, I don't know I would have been as friendly in responding to the review as you haha. 

I can try to after the https://github.com/e18e/e18e/issues/66 is done for sure!
author_association: CONTRIBUTOR
user: login: JounQin
created_at: 2025-05-20T18:42:09Z
body: > without that context, I don't know I would have been as friendly in responding to the review as you haha.

Actually I was thinking, why he has some many nitpicks? Seriously? Sad and uncomfortable, but finally got https://github.com/un-ts/eslint-plugin-import-x/pull/323#issuecomment-2895317502, thanks God. Haha.
author_association: MEMBER