remove eslint package support

Co-authored-by: Kent C. Dodds <me+github@kentcdodds.com>

Author: cursoragent

.github/DISCUSSION_TEMPLATE/eslint-suggestion.yml

@@ -5,11 +5,6 @@ contact_links:
     about:
       If you can't get something to work the way you expect, open a question in
       the discussions.
-  - name: 👮 ESLint Rule Suggestion
-    url: https://github.com/epicweb-dev/config/discussions/new?category=eslint-suggestion
-    about:
-      We appreciate you taking the time to improve `@epic-web/config` with your
-      ideas, but we use the Discussions for this instead of the issues tab 🙂.
   - name: 💬 Epic Web Discord Server
     url: https://kcd.im/discord
     about: Interact with other Epic Web developers

.github/ISSUE_TEMPLATE/config.yml

@@ -1,7 +1,7 @@
 <div>
   <h1 align="center"><a href="https://npm.im/@epic-web/config">👮 @epic-web/config</a></h1>
   <strong>
-    Reasonable ESLint, Oxlint, Prettier, and TypeScript configs for epic web devs
+    Reasonable Oxlint, Prettier, and TypeScript configs for epic web devs
   </strong>
   <p>
     This makes assumptions about the way you prefer to develop software and gives you configurations that will actually help you in your development.
@@ -40,8 +40,11 @@ configuring code quality tools or babysitting them.
 
 ## This solution
 
-This is a set of configurations you can use in your web projects to avoid
-wasting time.
+This package provides shared defaults for the tools this repo currently ships:
+
+- Oxlint
+- Prettier
+- TypeScript
 
 ## Decisions
 
@@ -114,33 +117,6 @@ Learn more from
 
 </details>
 
-### ESLint
-
-Create a `eslint.config.js` file in your project root with the following
-content:
-
-```js
-import { config as defaultConfig } from '@epic-web/config/eslint'
-
-/** @type {import("eslint").Linter.Config[]} */
-export default [...defaultConfig]
-```
-
-<details>
-  <summary>Customizing ESLint</summary>
-
-Learn more from
-[the Eslint docs here](https://eslint.org/docs/latest/extend/shareable-configs#overriding-settings-from-shareable-configs).
-
-</details>
-
-There are endless rules we could enable. However, we want to keep our
-configurations minimal and only enable rules that catch real problems (the kind
-that are likely to happen). This keeps our linting faster and reduces the number
-of false positives.
-
-Custom rule documentation lives in [`lint-rules/index.md`](./lint-rules/index.md).
-
 ### Oxlint
 
 Create a `.oxlintrc.json` file in your project root with the following content:
@@ -151,22 +127,28 @@ Create a `.oxlintrc.json` file in your project root with the following content:
 }
 ```
 
+This config includes the custom `epic-web/*` rules documented in
+[`lint-rules/index.md`](./lint-rules/index.md).
+
 Note: `typescript/no-misused-promises` and `typescript/no-floating-promises` are
 type-aware in Oxlint and require the type-aware setup described in the Oxlint
 docs.
 
-#### Unsupported rules
+Some Oxlint rule IDs still use the `eslint/` namespace because that is how
+Oxlint exposes those compatibility rules. You do not need to install ESLint to
+use them.
+
+#### Not yet covered
 
-The following ESLint rules/plugins from this config are not yet available in
-Oxlint, so they are intentionally omitted:
+The following rule families are intentionally omitted because they are not yet
+part of the Oxlint config this package ships:
 
 - `import/order`
 - `react-hooks/rules-of-hooks`
 - `react-hooks/exhaustive-deps`
-- `@typescript-eslint/no-unused-vars` (falls back to `eslint/no-unused-vars`)
 - `testing-library/*`
 - `jest-dom/*`
-- `vitest/*` (except `vitest/no-import-node-test`)
+- most `vitest/*` rules
 - `playwright/*`
 
 ## License

README.md

@@ -0,0 +1,41 @@
+# Move to Oxlint
+
+Date: 2026-03-26
+
+Status: accepted
+
+## Context
+
+This package originally shipped both ESLint and Oxlint configuration. Over time,
+the Oxlint side of the package became the simpler path to maintain and consume.
+
+There are a few reasons for that:
+
+1. Oxlint is dramatically faster, which makes local feedback and CI validation
+   cheaper.
+2. The configuration story is simpler when we only ship one linting toolchain.
+3. The Oxlint project has an active and clearly invested team behind it, which
+   makes it a good foundation to build on.
+4. Oxlint's compatibility with many established ESLint rule IDs makes migration
+   straightforward, so moving away from ESLint does not require a wholesale
+   rethink of the existing rule set.
+
+Because Oxlint can consume many familiar `eslint/...` rule identifiers and we
+already author our custom rules as Oxlint JS plugins, the migration path is
+mostly about removing duplicate package surface rather than redesigning the
+linting rules themselves.
+
+## Decision
+
+Ship Oxlint as the package's linting solution and remove the published ESLint
+configs, ESLint plugin entry points, and ESLint package dependencies.
+
+## Consequences
+
+- Consumers must migrate from the removed ESLint entry points to the Oxlint
+  config.
+- Some rule IDs may continue to use the `eslint/` namespace inside Oxlint
+  config, because that is how Oxlint exposes compatibility rules.
+- The package becomes smaller and easier to maintain because it only supports a
+  single linting toolchain.
+- Linting should be faster for both maintainers and consumers.

docs/decisions/010-move-to-oxlint.md

@@ -1073,10 +1073,9 @@ function calculateTotal(items: Array<number>) {
 
 Don't use semicolons. The rules for when you should use semicolons are more
 complicated than the rules for when you must use semicolons. With the right
-eslint rule
-([`no-unexpected-multiline`](https://eslint.org/docs/latest/rules/no-unexpected-multiline))
-and a formatter that will format your code funny for you if you mess up, you can
-avoid the pitfalls. Read more about this in
+Oxlint rule (`eslint/no-unexpected-multiline`) and a formatter that will format
+your code funny for you if you mess up, you can avoid the pitfalls. Read more
+about this in
 [Semicolons in JavaScript: A preference](https://kentcdodds.com/blog/semicolons-in-javascript-a-preference).
 
 <!-- prettier-ignore -->
@@ -1826,7 +1825,7 @@ test('Form shows error for invalid email', async () => {
 
 Prioritize your tests according to the Testing Trophy:
 
-1. Static Analysis (TypeScript, ESLint)
+1. Static Analysis (TypeScript, Oxlint)
 2. Unit Tests (Pure Functions)
 3. Integration Tests (Component Integration)
 4. E2E Tests (Critical User Flows)