eslint-plugin-nextfriday 3.0.0 → 3.2.0

package/CHANGELOG.md

@@ -1,5 +1,28 @@
 # eslint-plugin-nextfriday
 
+## 3.2.0
+
+### Minor Changes
+
+- [#118](https://github.com/next-friday/eslint-plugin-nextfriday/pull/118) [`143eee9`](https://github.com/next-friday/eslint-plugin-nextfriday/commit/143eee9fd0c6aed00e10677a6cad448dbdc9136e) Thanks [@joetakara](https://github.com/joetakara)! - Add `index-export-only` rule. Restricts `index.{js,jsx,ts,tsx}` files to imports, re-exports, and type/interface declarations only — flagging local function/class/variable declarations, inline `export const`/`export function`/`export class`, top-level expressions, and control flow. Type aliases, interfaces, and `export type` are allowed since they have no runtime cost. Included in `base`, `react`, and `nextjs` presets.
+
+- [#118](https://github.com/next-friday/eslint-plugin-nextfriday/pull/118) [`143eee9`](https://github.com/next-friday/eslint-plugin-nextfriday/commit/143eee9fd0c6aed00e10677a6cad448dbdc9136e) Thanks [@joetakara](https://github.com/joetakara)! - Add `no-inline-type-import` rule. Disallows inline `type` markers on import specifiers (`import { type Foo }` and `import { value, type Foo }`); auto-fix hoists single inline-type imports to `import type { ... }` and splits mixed value/type imports into two separate statements while preserving aliases, default specifiers, and quote style. Also strips redundant inline markers from existing `import type { ... }` statements. Included in `base`, `react`, and `nextjs` presets.
+
+## 3.1.0
+
+### Minor Changes
+
+- [#116](https://github.com/next-friday/eslint-plugin-nextfriday/pull/116) [`64ced55`](https://github.com/next-friday/eslint-plugin-nextfriday/commit/64ced556b4099a40ca2f4750523c7a079d2c81d8) Thanks [@joetakara](https://github.com/joetakara)! - `nextjs` and `nextjs/recommended` presets now also disable `nextfriday/file-kebab-case` (in addition to `nextfriday/jsx-pascal-case`) for files under `app/**`, `src/app/**`, `pages/**`, and `src/pages/**`. The override globs are expanded from `*.{jsx,tsx}` to `*.{js,jsx,ts,tsx}` so `route.ts`, `middleware.ts`, and other framework-named `.ts`/`.js` files in those directories are no longer flagged by either filename rule. Filename conventions in routing directories are owned by the framework, not by this plugin.
+
+  The `react` and `react/recommended` presets are unchanged — projects using them still enforce `file-kebab-case` on every `.ts`/`.js` and `jsx-pascal-case` on every `.tsx`/`.jsx`.
+
+### Patch Changes
+
+- [#116](https://github.com/next-friday/eslint-plugin-nextfriday/pull/116) [`64ced55`](https://github.com/next-friday/eslint-plugin-nextfriday/commit/64ced556b4099a40ca2f4750523c7a079d2c81d8) Thanks [@joetakara](https://github.com/joetakara)! - Documentation quality improvements targeting Context7 scoring gaps:
+  - `README.md` — "Per-Directory Configuration" section now explains how flat config resolves rules (config-array order, `files`/`ignores` precedence, why flat replaces `.eslintrc` overrides), adds a preset-tier-per-directory table, and lists common edge cases (glob ordering, top-level vs scoped `ignores`, spreading array-shaped presets, `--print-config` for debugging).
+  - `README.md` — "Migration Strategy" section is restructured around six concrete phases: surveying violations with `eslint --format json | jq`, isolating the auto-fix pass into its own PR, adopting the warn-level preset, ratcheting clean directories to `/recommended`, managing exceptions (severity override → directory override → disable comment, in that order of preference), and tracking violation count over time. The "Prioritize rules by impact" table is unchanged.
+  - `docs/rules/ENFORCE_CONSTANT_CASE.md` — Configuration section split into install / enable-just-this-rule / enable-with-related-rules / enable-via-preset / scope-to-directory subsections, plus a "Severity-only — no rule options" callout clarifying that the legacy `["error", { ... }]` array form is not accepted because no rule in this plugin has options.
+
 ## 3.0.0
 
 ### Major Changes

package/README.md

@@ -178,44 +178,115 @@ export default [
 
 ### Per-Directory Configuration
 
-ESLint flat config is an array of config objects. Each object's `files` and `ignores` glob patterns scope its rules to a subset of the project. Use this to apply different rule severities to different directories.
+#### How ESLint flat config resolves rules
+
+Flat config (the only format this plugin supports) is an **array of config objects** evaluated in order. For every file ESLint lints, it walks the array and merges every object whose `files` glob matches and whose `ignores` glob does not. Later objects override earlier ones rule-by-rule, so the **last matching object wins** for any given rule. Objects with no `files` field apply globally; objects with only `ignores` at the top level remove files from the entire run.
+
+This is why per-directory configuration works: you stack a global default first, then layer narrower `files`-scoped objects on top. ESLint 9+ also flattens nested arrays automatically, so spreading a preset that ships as an array (like `nextfriday.configs.nextjs`) works the same as spreading a single object.
+
+The legacy `.eslintrc` format used `overrides` and an inheritance tree to express the same thing. Flat config replaces that tree with a flat, deterministic array — easier to reason about, no implicit merging across `extends`, and no `parserOptions` plumbing per directory. The plugin does not ship `.eslintrc` shims, so projects on ESLint 8 or below cannot consume it without upgrading.
+
+#### Layering strict and loose presets
+
+Apply different rule severities to different directories by stacking config objects:
 
 ```js
 import nextfriday from "eslint-plugin-nextfriday";
 
 export default [
   {
-    files: ["src/components/**/*.{ts,tsx}"],
-    ...nextfriday.configs["react/recommended"],
+    ignores: ["src/legacy/**", "dist/**", "build/**", "**/*.generated.ts"],
   },
 
+  nextfriday.configs.react,
+
   {
-    files: ["src/utils/**/*.ts"],
-    ...nextfriday.configs.base,
+    files: ["src/components/**/*.{ts,tsx}", "src/hooks/**/*.{ts,tsx}"],
+    ...nextfriday.configs["react/recommended"],
   },
 
   {
-    files: ["src/legacy/**/*.{ts,tsx}"],
-    ignores: ["src/legacy/**/*"],
+    files: ["src/utils/**/*.ts", "src/lib/**/*.ts"],
+    rules: {
+      "nextfriday/require-explicit-return-type": "error",
+      "nextfriday/no-relative-imports": "error",
+    },
   },
 
   {
-    files: ["**/*.test.{ts,tsx}"],
+    files: ["**/*.{test,spec}.{ts,tsx}"],
     rules: {
       "nextfriday/require-explicit-return-type": "off",
       "nextfriday/no-single-char-variables": "off",
+      "nextfriday/no-direct-date": "off",
     },
   },
 ];
 ```
 
-The first config block applies the strict `react/recommended` preset (errors) to component files. The second applies the looser `base` preset (warnings) to utilities. The third excludes legacy code from linting entirely. The fourth keeps lint enabled for tests but turns off rules that conflict with common test patterns.
+Reading top to bottom:
+
+1. **Top-level `ignores`** removes legacy and build artifacts from the entire run. A config object containing _only_ `ignores` is treated as a global ignore — narrower `ignores` inside a `files`-scoped object only affect that object.
+2. **`nextfriday.configs.react`** applies as the warn-level baseline to every file ESLint sees (no `files` glob).
+3. **Component and hook directories** get promoted to `react/recommended` (errors). Because this object comes after the baseline, its severities win.
+4. **Utility directories** keep the warn-level baseline but selectively promote two correctness rules to `error`. Use this pattern when you don't want the full `/recommended` preset but do want specific rules treated as blocking.
+5. **Test files** keep most rules but turn off rules that conflict with common test patterns (single-letter loop counters, frozen `Date.now()` mocks, void-returning `it()` callbacks).
+
+#### Choosing a preset tier per directory
+
+| Code area                         | Suggested preset                            | Why                                                                        |
+| --------------------------------- | ------------------------------------------- | -------------------------------------------------------------------------- |
+| Library / SDK code                | `base/recommended` or `react/recommended`   | Public surface should be tightest. `error` blocks regressions at PR time.  |
+| New product code                  | `react/recommended` or `nextjs/recommended` | New code starts clean; lock the conventions in immediately.                |
+| Mature product code mid-migration | `react` or `nextjs` (warn)                  | Ship while migrating. Switch to `/recommended` after a clean run.          |
+| Tests, scripts, fixtures          | preset + targeted overrides                 | Keep the core lint signal; turn off rules that mismatch test/CLI patterns. |
+| Legacy / vendored / generated     | top-level `ignores`                         | No lint signal at all. Don't waste reviewer attention or CI time.          |
+
+#### Edge cases and troubleshooting
+
+- **Glob precedence is order-dependent, not specificity-based.** A more specific glob later in the array wins; a more specific glob _earlier_ in the array does not. If `files: ["src/**"]` appears after `files: ["src/components/**"]`, the broader rule set wins for components. Put broader configs first.
+- **`files` and `ignores` are anchored to the project root** (the directory containing `eslint.config.{js,mjs,ts}`), not the file's directory. Use `**/` prefixes for matches anywhere in the tree (e.g., `**/*.test.ts`).
+- **Top-level `ignores` ≠ `ignores` inside a config object.** A standalone object `{ ignores: [...] }` removes files from the entire run; an `ignores` field next to `files` and `rules` only narrows that one config object's match.
+- **Spreading a preset replaces, not merges, the `plugins` field.** If you spread `...nextfriday.configs.react` and then a different config later, the later object's `plugins` wins. Re-declare `plugins: { nextfriday }` if you add rules in a later object.
+- **`nextfriday.configs.nextjs` is an array, not a single object.** Spreading it inline with `...nextfriday.configs.nextjs` only spreads array indices, not the inner objects. Use it as an array entry (`nextfriday.configs.nextjs,`) instead, so ESLint 9+ flattens it.
+- **Two presets in one project.** Use scoped `files` rather than two unscoped presets — unscoped presets stack and the later one's rule severities win for every file, which is rarely what you want.
+- **Verifying the resolved config for a file:** `pnpm eslint --print-config path/to/file.tsx` prints the merged config ESLint would actually use. Reach for this when a rule fires (or doesn't) and you can't tell why.
 
 ### Migration Strategy
 
-For an existing codebase with many violations, enable rules gradually instead of all at once. Three patterns, in order of how disruptive each is to your team:
+For an existing codebase with many violations, treat the migration as a phased rollout — survey, fix, lock in, repeat.
+
+#### 1. Survey violations before changing anything
+
+Install the plugin as a dev dependency, drop a warn-level preset into `eslint.config.mjs`, and run a read-only lint. Don't `--fix` yet — you want to see the raw shape of the codebase first.
+
+```bash
+pnpm add -D eslint-plugin-nextfriday eslint
+pnpm eslint . --no-fix
+```
+
+Group violations by rule so you can plan the work. Most CI dashboards do this for you, but a one-liner works locally:
+
+```bash
+pnpm eslint . --no-fix --format json | jq -r '.[].messages[].ruleId' | sort | uniq -c | sort -rn
+```
+
+The output tells you which rules account for most of the noise. A rule with 3 violations is a 10-minute fix; a rule with 800 is a multi-week project. Plan accordingly.
+
+#### 2. Run the auto-fixers in an isolated PR
+
+Roughly a third of this plugin's rules are auto-fixable (the `Fixable ✅` column in the [Rules](#rules) table). Run them in a dedicated commit so the diff is purely mechanical and reviewers don't have to read every line:
+
+```bash
+pnpm eslint . --fix
+git add -u && git commit -m "style(lint): autofix nextfriday rules"
+```
+
+Open this as its own PR. Mixing auto-fix output with hand-written changes in the same diff makes review almost impossible.
+
+#### 3. Adopt the warn-level preset
 
-**1. Start with the warn-level preset.** All rules surface as warnings, so the build still passes. Fix issues at your own pace, then switch to `/recommended`.
+After the auto-fix pass, drop in the warn-level preset so the remaining violations surface during local dev and CI without breaking the build:
 
 ```js
 import nextfriday from "eslint-plugin-nextfriday";
@@ -223,7 +294,11 @@ import nextfriday from "eslint-plugin-nextfriday";
 export default [nextfriday.configs.react];
 ```
 
-**2. Lock-in a clean directory at a time.** Use `files` to apply `/recommended` (errors) only where the code is already clean, and the warn-level preset everywhere else.
+Warnings don't fail `eslint --max-warnings=0`, so add that flag in CI only when you're ready to block on warnings. Until then, warnings are visible signal without pressure.
+
+#### 4. Lock in clean directories one at a time
+
+As individual directories or features reach zero violations, promote them to `/recommended` (errors) so regressions block at PR time. Everything else stays on the warn-level preset.
 
 ```js
 import nextfriday from "eslint-plugin-nextfriday";
@@ -238,11 +313,15 @@ export default [
 ];
 ```
 
-**3. Disable individual rules until the codebase is ready.** Re-declare specific rules with a lower severity (or `"off"`) after spreading the preset. Useful when one rule produces too much noise to fix at once.
+Repeat per directory. This is how you ratchet without flag-day rewrites.
 
-```js
-import nextfriday from "eslint-plugin-nextfriday";
+#### 5. Manage exceptions explicitly
+
+Three ways to carve out an exception, in order of preference. Pick the narrowest one that solves the problem.
 
+**Per-rule severity override** — turn off a single noisy rule globally until you can fix it at the codebase level:
+
+```js
 export default [
   nextfriday.configs["react/recommended"],
 
@@ -255,14 +334,56 @@ export default [
 ];
 ```
 
-Pair these with `ignores` to skip vendored or generated files entirely:
+**Per-directory exception** — keep the rule strict everywhere except one stubborn corner:
+
+```js
+export default [
+  nextfriday.configs["react/recommended"],
+
+  {
+    files: ["src/legacy/**/*.{ts,tsx}"],
+    rules: {
+      "nextfriday/no-relative-imports": "off",
+      "nextfriday/enforce-camel-case": "off",
+    },
+  },
+];
+```
+
+**Per-file or per-line disable comments** — last resort, for genuinely irreducible cases:
+
+```ts
+// eslint-disable-next-line nextfriday/no-direct-date
+const epochAnchor = new Date(0);
+
+/* eslint-disable nextfriday/no-emoji */
+export const FLAG_EMOJIS = ["🇹🇭", "🇯🇵", "🇺🇸"];
+/* eslint-enable nextfriday/no-emoji */
+```
+
+Always disable a _named_ rule, never blanket-disable ESLint. A blanket `// eslint-disable` mutes every rule including correctness ones, so legitimate bugs slip through later.
+
+**Skip vendored or generated files entirely** with a top-level ignore — these aren't exceptions to manage, they're code you don't lint at all:
 
 ```js
-{
-  ignores: ["dist/**", "build/**", "**/*.generated.ts"],
-}
+export default [
+  {
+    ignores: ["dist/**", "build/**", "coverage/**", "**/*.generated.ts"],
+  },
+
+  nextfriday.configs["react/recommended"],
+];
 ```
 
+#### 6. Track progress so the migration actually lands
+
+Migrations stall when nobody can see how close you are. Two cheap signals:
+
+- **Violation count over time.** Pipe `pnpm eslint . --no-fix --format compact | wc -l` into your CI metrics or a daily Slack post. Trend it weekly. If the number stops dropping, the migration has stalled.
+- **Verify a single file's resolved config.** When a contributor asks "why did this rule fire on my file?", run `pnpm eslint --print-config path/to/file.tsx`. The output shows exactly which severity ESLint resolved for every rule on that file — usually answers the question in seconds.
+
+Once a directory hits zero, lock it in (step 4). Once the warn-level count hits zero across the whole repo, switch the global preset to `/recommended` and add `--max-warnings=0` to CI. The migration is done.
+
 #### Prioritize rules by impact
 
 When the warn-level preset surfaces hundreds of violations, fix them in this order — high-impact rules catch real bugs, while low-impact rules are style preferences that can wait.
@@ -313,6 +434,7 @@ In practice: turn the high tier on as `"error"` first, leave the medium tier as
 | [enforce-sorted-destructuring](docs/rules/ENFORCE_SORTED_DESTRUCTURING.md)   | Enforce alphabetical sorting of destructured properties                | ✅      |
 | [no-env-fallback](docs/rules/NO_ENV_FALLBACK.md)                             | Disallow fallback values for environment variables                     | ❌      |
 | [no-inline-default-export](docs/rules/NO_INLINE_DEFAULT_EXPORT.md)           | Disallow inline default exports - declare first, then export           | ❌      |
+| [index-export-only](docs/rules/INDEX_EXPORT_ONLY.md)                         | Restrict index files to imports, re-exports, and type declarations     | ❌      |
 | [no-direct-date](docs/rules/NO_DIRECT_DATE.md)                               | Disallow direct usage of Date constructor and methods                  | ❌      |
 | [newline-after-multiline-block](docs/rules/NEWLINE_AFTER_MULTILINE_BLOCK.md) | Require a blank line after multi-line statements                       | ✅      |
 | [newline-before-return](docs/rules/NEWLINE_BEFORE_RETURN.md)                 | Require a blank line before return statements                          | ✅      |
@@ -328,6 +450,7 @@ In practice: turn the high tier on as `"error"` first, leave the medium tier as
 | Rule                                                                 | Description                                               | Fixable |
 | -------------------------------------------------------------------- | --------------------------------------------------------- | ------- |
 | [no-relative-imports](docs/rules/NO_RELATIVE_IMPORTS.md)             | Disallow relative imports with ../ - use absolute imports | ❌      |
+| [no-inline-type-import](docs/rules/NO_INLINE_TYPE_IMPORT.md)         | Disallow inline 'type' markers - hoist or split imports   | ✅      |
 | [prefer-import-type](docs/rules/PREFER_IMPORT_TYPE.md)               | Enforce using 'import type' for type-only imports         | ✅      |
 | [prefer-react-import-types](docs/rules/PREFER_REACT_IMPORT_TYPES.md) | Enforce direct imports from 'react' instead of React.X    | ✅      |
 | [sort-exports](docs/rules/SORT_EXPORTS.md)                           | Enforce a consistent ordering of export groups            | ✅      |
@@ -377,14 +500,16 @@ In practice: turn the high tier on as `"error"` first, leave the medium tier as
 
 | Preset               | Severity | Base Rules | JSX Rules | Next.js Rules | Total Rules |
 | -------------------- | -------- | ---------- | --------- | ------------- | ----------- |
-| `base`               | warn     | 40         | 0         | 0             | 40          |
-| `base/recommended`   | error    | 40         | 0         | 0             | 40          |
-| `react`              | warn     | 40         | 15        | 0             | 55          |
-| `react/recommended`  | error    | 40         | 15        | 0             | 55          |
-| `nextjs`             | warn     | 40         | 15        | 1             | 56          |
-| `nextjs/recommended` | error    | 40         | 15        | 1             | 56          |
+| `base`               | warn     | 42         | 0         | 0             | 42          |
+| `base/recommended`   | error    | 42         | 0         | 0             | 42          |
+| `react`              | warn     | 42         | 16        | 0             | 58          |
+| `react/recommended`  | error    | 42         | 16        | 0             | 58          |
+| `nextjs`             | warn     | 42         | 16        | 1             | 59          |
+| `nextjs/recommended` | error    | 42         | 16        | 1             | 59          |
+
+The `nextjs` and `nextjs/recommended` presets ship as an array of two flat-config objects: the rule set above, plus a routing override that disables `nextfriday/file-kebab-case` and `nextfriday/jsx-pascal-case` for files matching `app/**/*.{js,jsx,ts,tsx}`, `src/app/**/*.{js,jsx,ts,tsx}`, `pages/**/*.{js,jsx,ts,tsx}`, and `src/pages/**/*.{js,jsx,ts,tsx}`. Next.js owns the filenames in those directories (`page.tsx`, `layout.tsx`, `route.ts`, `middleware.ts`, etc.), so the plugin steps out of the way. ESLint 9+ flattens nested config arrays automatically, so spreading the preset works as expected.
 
-### Base Configuration Rules (40 rules)
+### Base Configuration Rules (42 rules)
 
 Included in `base`, `base/recommended`, and all other presets:
 
@@ -398,6 +523,7 @@ Included in `base`, `base/recommended`, and all other presets:
 - `nextfriday/enforce-sorted-destructuring`
 - `nextfriday/enforce-type-declaration-order`
 - `nextfriday/file-kebab-case`
+- `nextfriday/index-export-only`
 - `nextfriday/newline-after-multiline-block`
 - `nextfriday/newline-before-return`
 - `nextfriday/no-complex-inline-return`
@@ -407,6 +533,7 @@ Included in `base`, `base/recommended`, and all other presets:
 - `nextfriday/no-inline-default-export`
 - `nextfriday/no-inline-nested-object`
 - `nextfriday/no-inline-return-properties`
+- `nextfriday/no-inline-type-import`
 - `nextfriday/no-lazy-identifiers`
 - `nextfriday/no-logic-in-params`
 - `nextfriday/no-misleading-constant-case`

package/docs/rules/ENFORCE_CONSTANT_CASE.md

@@ -58,7 +58,36 @@ function foo() {
 
 ## Configuration
 
-This rule pairs with [`no-misleading-constant-case`](./NO_MISLEADING_CONSTANT_CASE.md) so that static globals use `SCREAMING_SNAKE_CASE` while local scopes and dynamic values keep `camelCase`. ESLint 9+ flat config:
+This rule has no options — only severity is configurable (`"error"`, `"warn"`, `"off"`). It pairs with [`no-misleading-constant-case`](./NO_MISLEADING_CONSTANT_CASE.md) so that static globals use `SCREAMING_SNAKE_CASE` while local scopes and dynamic values keep `camelCase`.
+
+### Install
+
+```bash
+pnpm add -D eslint-plugin-nextfriday eslint
+# npm install --save-dev eslint-plugin-nextfriday eslint
+# yarn add --dev eslint-plugin-nextfriday eslint
+```
+
+### Enable just this rule
+
+Use this when you want the rule but not the rest of the preset (e.g., adopting one rule at a time during a migration). The `plugins` field registers the plugin under the `nextfriday` namespace; the `rules` field turns on the rule by name:
+
+```js
+import nextfriday from "eslint-plugin-nextfriday";
+
+export default [
+  {
+    plugins: { nextfriday },
+    rules: {
+      "nextfriday/enforce-constant-case": "error",
+    },
+  },
+];
+```
+
+### Enable with related rules
+
+Constants, locals, and dynamic values each need a different naming convention. Enable the trio together so violations from any direction surface:
 
 ```js
 import nextfriday from "eslint-plugin-nextfriday";
@@ -75,7 +104,9 @@ export default [
 ];
 ```
 
-Or via a preset (every preset already enables all three at the configured severity):
+### Enable via a preset
+
+Every preset includes this rule at the preset's severity (`warn` or `error`). This is the simplest setup and the recommended one for most projects:
 
 ```js
 import nextfriday from "eslint-plugin-nextfriday";
@@ -83,7 +114,38 @@ import nextfriday from "eslint-plugin-nextfriday";
 export default [nextfriday.configs["base/recommended"]];
 ```
 
-This plugin only supports ESLint 9+ flat config — legacy `.eslintrc` is not supported.
+### Scope to a directory
+
+If you're migrating an existing codebase, scope the rule to a clean directory first and leave the rest of the project on `"warn"` until you've fixed the violations there. ESLint 9+ flat config layers configs in array order; the later object's severity wins for any file matching its `files` glob:
+
+```js
+import nextfriday from "eslint-plugin-nextfriday";
+
+export default [
+  nextfriday.configs.base,
+
+  {
+    files: ["src/config/**/*.ts", "src/lib/**/*.ts"],
+    rules: {
+      "nextfriday/enforce-constant-case": "error",
+    },
+  },
+];
+```
+
+### Severity-only — no rule options
+
+Each rule in this plugin uses `schema: []` and `defaultOptions: []` (no options). The flat-config value is **only** the severity string — `"error"`, `"warn"`, or `"off"`. The legacy `["error", { ... }]` array form is not accepted because there are no options to pass.
+
+```js
+// Correct
+"nextfriday/enforce-constant-case": "error"
+
+// Won't apply — there are no options to override
+"nextfriday/enforce-constant-case": ["error", { allowCamelCase: true }]
+```
+
+This plugin only supports ESLint 9+ flat config — legacy `.eslintrc` is not supported. Projects on ESLint 8 or below cannot consume it without upgrading.
 
 ## When Not To Use It
 

package/docs/rules/FILE_KEBAB_CASE.md

@@ -40,9 +40,15 @@ This rule enforces that all TypeScript (.ts) and JavaScript (.js) files use keba
 - **Numbers are allowed inside segments.** `file-with-numbers-123.ts` ✓
 - **Single-word filenames are valid.** `single.ts` ✓ (no hyphens needed)
 
+## Scoping the Rule
+
+This rule has **no built-in framework detection**. It checks every `.ts`/`.js` file it sees against kebab-case. In Next.js projects, routing directories (`app/`, `pages/`) contain framework-named files (`route.ts`, `middleware.ts`) that already happen to be kebab-case — but if you colocate helpers there with non-kebab names (`useThing.ts`, `MyHelper.ts`), the rule will flag them.
+
+The `nextjs` and `nextjs/recommended` presets ship with an override that **automatically disables this rule** for files under `app/**`, `src/app/**`, `pages/**`, and `src/pages/**` (matched against `*.{js,jsx,ts,tsx}`). Filename conventions in those directories are owned by the framework, not by this plugin. The `base` and `react` presets do **not** include this override — they enforce `file-kebab-case` on every `.ts`/`.js` regardless of directory.
+
 ## Disabling the Rule
 
-To opt out for a specific directory or file pattern, add an override in your flat config:
+To opt out for additional directories or file patterns, add an override in your flat config:
 
 ```js
 import nextfriday from "eslint-plugin-nextfriday";

package/docs/rules/INDEX_EXPORT_ONLY.md

@@ -0,0 +1,88 @@
+# index-export-only
+
+Restrict `index` files to imports, re-exports, and type declarations only.
+
+## Rule Details
+
+This rule enforces that `index.{js,jsx,ts,tsx}` files act purely as barrel files. Any runtime declaration — functions, classes, variables, top-level expressions, or inline `export const`/`export function`/`export class` — must live in its own module and be re-exported from the index.
+
+The rule applies only when the basename of the file is `index`. Files like `index.test.ts`, `index.spec.ts`, or `index.d.ts` are not affected.
+
+### Why?
+
+Index files are entry points. Mixing implementation into them obscures where behavior lives, breaks file-based code navigation, and makes the import surface harder to refactor. A barrel file should describe the public API of a directory — nothing more.
+
+## Examples
+
+### Incorrect
+
+```ts
+import { clsx, type ClassValue } from "clsx";
+import { twMerge } from "tailwind-merge";
+
+function cn(...inputs: ClassValue[]): string {
+  return twMerge(clsx(inputs));
+}
+
+export { cn };
+```
+
+```ts
+export const VERSION = "1.0.0";
+
+export function helper() {
+  return 1;
+}
+
+export class Service {}
+```
+
+```ts
+console.log("loaded");
+```
+
+### Correct
+
+```ts
+export { cn } from "./cn";
+export * from "./types";
+export type { Props } from "./props";
+export { default as Button } from "./button";
+```
+
+```ts
+import button from "./button";
+
+export default button;
+```
+
+```ts
+export type Foo = string;
+export interface Bar {
+  id: string;
+}
+```
+
+## What This Rule Allows
+
+- `import` statements (including side-effect imports like `import "./styles.css"`)
+- Specifier-only `export` and `export ... from` re-exports
+- `export *` and `export * as ns` re-exports
+- `export default identifier` where the identifier comes from an import
+- Top-level `type` aliases and `interface` declarations (they have no runtime cost)
+- `export type` and `export interface` declarations
+
+## What This Rule Disallows
+
+- `function`, `class`, and `const`/`let`/`var` declarations at the top level
+- Inline `export function`, `export class`, `export const`, `export let`, `export var`
+- `export default` of a function/class/literal/object expression
+- Top-level expression statements and control flow (`console.log(...)`, `if`, `for`, etc.)
+
+## When Not To Use It
+
+If your project intentionally mixes implementation and re-exports in index files — for example, a single-file utility library where `index.ts` is the only source file — disable this rule.
+
+## Related Rules
+
+- [no-inline-default-export](./NO_INLINE_DEFAULT_EXPORT.md) - Disallow inline default and named exports across all files

package/docs/rules/JSX_PASCAL_CASE.md

@@ -30,7 +30,11 @@ This rule enforces that JSX and TSX files use PascalCase naming convention for t
 
 ## Scoping the Rule
 
-This rule has **no built-in framework detection** and no allowlist of "known" filenames. It checks every `.jsx`/`.tsx` it sees. If your project mixes component files with framework routing files that use lowercase names (e.g. Next.js App Router `page.tsx`, `layout.tsx`, `error.tsx`, or Pages Router `_app.tsx`), scope the rule explicitly via ESLint's `files` glob in flat config:
+This rule has **no built-in framework detection** and no allowlist of "known" filenames. It checks every `.jsx`/`.tsx` it sees against PascalCase.
+
+The `nextjs` and `nextjs/recommended` presets ship with an override that **automatically disables this rule** for files under `app/**`, `src/app/**`, `pages/**`, and `src/pages/**` — Next.js owns those filenames (`page.tsx`, `layout.tsx`, `error.tsx`, etc.). If you use a `nextjs` preset, you do not need to add a routing override yourself.
+
+The `base` and `react` presets do **not** include this override. If you use `react` on a Next.js project (or any project that mixes PascalCase component files with lowercase framework routing files), scope the rule explicitly via ESLint's `files` glob:
 
 ```js
 import nextfriday from "eslint-plugin-nextfriday";
@@ -56,7 +60,7 @@ export default [
 
 The first override turns the rule on only inside component directories where PascalCase is the convention. The second override explicitly disables the rule for Next.js routing directories where the framework owns the filename.
 
-The plugin deliberately does not try to detect Next.js, Remix, or other framework conventions automatically — folder structures vary across projects (monorepos, custom `app` locations, hybrid Pages + App Router setups), and a built-in allowlist would inevitably go stale. ESLint's `files` glob is the deterministic way to express the scope you actually want.
+The plugin deliberately does not try to detect Next.js, Remix, or other framework conventions outside of the `nextjs` preset — folder structures vary across projects (monorepos, custom `app` locations, hybrid Pages + App Router setups), and a built-in allowlist would inevitably go stale. ESLint's `files` glob is the deterministic way to express the scope you actually want.
 
 ## When Not To Use It
 

package/docs/rules/NO_INLINE_TYPE_IMPORT.md

@@ -0,0 +1,86 @@
+# no-inline-type-import
+
+Disallow inline `type` markers on import specifiers. Use `import type` or split into a separate type-only import statement.
+
+> This rule is auto-fixable using `--fix`.
+
+## Rule Details
+
+This rule forbids the inline-`type` form `import { type Foo }` and the mixed form `import { value, type Foo }`. Type-only imports must be expressed at the statement level with `import type { ... }`. When value and type imports come from the same module, the rule splits them into two separate statements.
+
+### Why?
+
+Statement-level `import type` makes the runtime cost of every import unambiguous at a glance, simplifies tooling that distinguishes erased imports from real ones (bundlers, type-only emit, transpilers), and removes the need for readers to scan each specifier for an inline keyword.
+
+## Examples
+
+### Incorrect
+
+```ts
+import { type foo } from "bar";
+
+import { baz, type moo } from "mee";
+
+import Default, { value, type Foo } from "src";
+```
+
+### Correct
+
+```ts
+import type { foo } from "bar";
+
+import { baz } from "mee";
+import type { moo } from "mee";
+
+import Default, { value } from "src";
+import type { Foo } from "src";
+```
+
+## Auto-fixing
+
+The rule's `--fix` produces these transformations:
+
+```ts
+// Single inline type → hoisted
+import { type foo } from "bar";
+// becomes
+import type { foo } from "bar";
+
+// All inline types → hoisted
+import { type foo, type bar } from "src";
+// becomes
+import type { foo, bar } from "src";
+
+// Mixed value + inline type → split
+import { baz, type moo } from "mee";
+// becomes
+import { baz } from "mee";
+import type { moo } from "mee";
+
+// Default + inline type → split
+import Default, { type Foo } from "src";
+// becomes
+import Default from "src";
+import type { Foo } from "src";
+
+// Aliases are preserved
+import { foo as bar, type baz as qux } from "src";
+// becomes
+import { foo as bar } from "src";
+import type { baz as qux } from "src";
+
+// Redundant inline markers inside `import type` are stripped
+import type { foo, type bar } from "src";
+// becomes
+import type { foo, bar } from "src";
+```
+
+After auto-fix, other import-ordering rules (such as `sort-imports`) may re-order the resulting statements according to their own grouping rules.
+
+## When Not To Use It
+
+If your codebase intentionally uses the inline `type` form to keep value and type imports adjacent in a single statement, disable this rule.
+
+## Related Rules
+
+- [prefer-import-type](./PREFER_IMPORT_TYPE.md) - Hoists imports that are used only as types to `import type`. Complements this rule for usage-based detection.