eslint-plugin-typefest 1.2.1 → 1.2.3

package/dist/rules/prefer-type-fest-union-length.d.ts

@@ -0,0 +1,13 @@
+import { createTypedRule } from "../_internal/typed-rule.js";
+/**
+ * ESLint rule definition for `prefer-type-fest-union-length`.
+ *
+ * @remarks
+ * Defines metadata, diagnostics, and suggestions/fixes for this rule.
+ */
+declare const preferTypeFestUnionLengthRule: ReturnType<typeof createTypedRule>;
+/**
+ * Default export for the `prefer-type-fest-union-length` rule module.
+ */
+export default preferTypeFestUnionLengthRule;
+//# sourceMappingURL=prefer-type-fest-union-length.d.ts.map

package/dist/rules/prefer-type-fest-union-length.d.ts.map

@@ -0,0 +1 @@
+{"version":3,"file":"prefer-type-fest-union-length.d.ts","sourceRoot":"","sources":["../../src/rules/prefer-type-fest-union-length.ts"],"names":[],"mappings":"AAcA,OAAO,EAAE,eAAe,EAAE,MAAM,4BAA4B,CAAC;AAE7D;;;;;GAKG;AACH,QAAA,MAAM,6BAA6B,EAAE,UAAU,CAAC,OAAO,eAAe,CAoFhE,CAAC;AAEP;;GAEG;AACH,eAAe,6BAA6B,CAAC"}

package/dist/rules/prefer-type-fest-union-length.js

@@ -0,0 +1,75 @@
+import { arrayFirst } from "ts-extras";
+import { collectDirectNamedImportsFromSource, createSafeTypeNodeTextReplacementFix, } from "../_internal/imported-type-aliases.js";
+import { TYPE_FEST_MODULE_SOURCE } from "../_internal/module-source.js";
+import { reportWithOptionalFix } from "../_internal/rule-reporting.js";
+import { createTypedRule } from "../_internal/typed-rule.js";
+/**
+ * ESLint rule definition for `prefer-type-fest-union-length`.
+ *
+ * @remarks
+ * Defines metadata, diagnostics, and suggestions/fixes for this rule.
+ */
+const preferTypeFestUnionLengthRule = createTypedRule({
+    create(context) {
+        const typeFestDirectImports = collectDirectNamedImportsFromSource(context.sourceCode, TYPE_FEST_MODULE_SOURCE);
+        return {
+            TSIndexedAccessType(node) {
+                const { indexType, objectType } = node;
+                // Require: objectType is TSTypeReference named "UnionToTuple"
+                if (objectType.type !== "TSTypeReference" ||
+                    objectType.typeName.type !== "Identifier" ||
+                    objectType.typeName.name !== "UnionToTuple") {
+                    return;
+                }
+                // Require: indexType is TSLiteralType with string literal "length"
+                if (indexType.type !== "TSLiteralType" ||
+                    indexType.literal.type !== "Literal" ||
+                    indexType.literal.value !== "length") {
+                    return;
+                }
+                // Require: UnionToTuple has exactly one type argument to forward
+                const typeParams = objectType.typeArguments?.params;
+                if (typeParams?.length !== 1) {
+                    return;
+                }
+                const typeArgText = context.sourceCode.getText(arrayFirst(typeParams));
+                const replacementText = `UnionLength<${typeArgText}>`;
+                const replacementFix = createSafeTypeNodeTextReplacementFix(node, "UnionLength", replacementText, typeFestDirectImports);
+                reportWithOptionalFix({
+                    context,
+                    fix: replacementFix,
+                    messageId: "preferUnionLength",
+                    node,
+                });
+            },
+        };
+    },
+    meta: {
+        deprecated: false,
+        docs: {
+            description: "require TypeFest `UnionLength` over `UnionToTuple<T>['length']`.",
+            frozen: false,
+            recommended: true,
+            requiresTypeChecking: false,
+            typefestConfigs: [
+                "typefest.configs.recommended",
+                "typefest.configs.strict",
+                "typefest.configs.all",
+                "typefest.configs.type-fest/types",
+            ],
+            url: "https://nick2bad4u.github.io/eslint-plugin-typefest/docs/rules/prefer-type-fest-union-length",
+        },
+        fixable: "code",
+        messages: {
+            preferUnionLength: "Prefer `UnionLength<T>` from type-fest over `UnionToTuple<T>['length']`.",
+        },
+        schema: [],
+        type: "suggestion",
+    },
+    name: "prefer-type-fest-union-length",
+});
+/**
+ * Default export for the `prefer-type-fest-union-length` rule module.
+ */
+export default preferTypeFestUnionLengthRule;
+//# sourceMappingURL=prefer-type-fest-union-length.js.map

package/dist/rules/prefer-type-fest-union-length.js.map

@@ -0,0 +1 @@
+{"version":3,"file":"prefer-type-fest-union-length.js","sourceRoot":"","sources":["../../src/rules/prefer-type-fest-union-length.ts"],"names":[],"mappings":"AAMA,OAAO,EAAE,UAAU,EAAE,MAAM,WAAW,CAAC;AAEvC,OAAO,EACH,mCAAmC,EACnC,oCAAoC,GACvC,MAAM,uCAAuC,CAAC;AAC/C,OAAO,EAAE,uBAAuB,EAAE,MAAM,+BAA+B,CAAC;AACxE,OAAO,EAAE,qBAAqB,EAAE,MAAM,gCAAgC,CAAC;AACvE,OAAO,EAAE,eAAe,EAAE,MAAM,4BAA4B,CAAC;AAE7D;;;;;GAKG;AACH,MAAM,6BAA6B,GAC/B,eAAe,CAAC;IACZ,MAAM,CAAC,OAAO;QACV,MAAM,qBAAqB,GAAG,mCAAmC,CAC7D,OAAO,CAAC,UAAU,EAClB,uBAAuB,CAC1B,CAAC;QAEF,OAAO;YACH,mBAAmB,CACf,IAA4C;gBAE5C,MAAM,EAAE,SAAS,EAAE,UAAU,EAAE,GAAG,IAAI,CAAC;gBAEvC,8DAA8D;gBAC9D,IACI,UAAU,CAAC,IAAI,KAAK,iBAAiB;oBACrC,UAAU,CAAC,QAAQ,CAAC,IAAI,KAAK,YAAY;oBACzC,UAAU,CAAC,QAAQ,CAAC,IAAI,KAAK,cAAc,EAC7C,CAAC;oBACC,OAAO;gBACX,CAAC;gBAED,mEAAmE;gBACnE,IACI,SAAS,CAAC,IAAI,KAAK,eAAe;oBAClC,SAAS,CAAC,OAAO,CAAC,IAAI,KAAK,SAAS;oBACpC,SAAS,CAAC,OAAO,CAAC,KAAK,KAAK,QAAQ,EACtC,CAAC;oBACC,OAAO;gBACX,CAAC;gBAED,iEAAiE;gBACjE,MAAM,UAAU,GAAG,UAAU,CAAC,aAAa,EAAE,MAAM,CAAC;gBACpD,IAAI,UAAU,EAAE,MAAM,KAAK,CAAC,EAAE,CAAC;oBAC3B,OAAO;gBACX,CAAC;gBAED,MAAM,WAAW,GAAG,OAAO,CAAC,UAAU,CAAC,OAAO,CAC1C,UAAU,CAAC,UAAU,CAAkB,CAC1C,CAAC;gBACF,MAAM,eAAe,GAAG,eAAe,WAAW,GAAG,CAAC;gBAEtD,MAAM,cAAc,GAAG,oCAAoC,CACvD,IAAI,EACJ,aAAa,EACb,eAAe,EACf,qBAAqB,CACxB,CAAC;gBAEF,qBAAqB,CAAC;oBAClB,OAAO;oBACP,GAAG,EAAE,cAAc;oBACnB,SAAS,EAAE,mBAAmB;oBAC9B,IAAI;iBACP,CAAC,CAAC;YACP,CAAC;SACJ,CAAC;IACN,CAAC;IACD,IAAI,EAAE;QACF,UAAU,EAAE,KAAK;QACjB,IAAI,EAAE;YACF,WAAW,EACP,kEAAkE;YACtE,MAAM,EAAE,KAAK;YACb,WAAW,EAAE,IAAI;YACjB,oBAAoB,EAAE,KAAK;YAC3B,eAAe,EAAE;gBACb,8BAA8B;gBAC9B,yBAAyB;gBACzB,sBAAsB;gBACtB,kCAAkC;aACrC;YACD,GAAG,EAAE,8FAA8F;SACtG;QACD,OAAO,EAAE,MAAM;QACf,QAAQ,EAAE;YACN,iBAAiB,EACb,0EAA0E;SACjF;QACD,MAAM,EAAE,EAAE;QACV,IAAI,EAAE,YAAY;KACrB;IACD,IAAI,EAAE,+BAA+B;CACxC,CAAC,CAAC;AAEP;;GAEG;AACH,eAAe,6BAA6B,CAAC"}

package/docs/rules/prefer-ts-extras-assert-never.md

@@ -0,0 +1,112 @@
+# prefer-ts-extras-assert-never
+
+Require [`assertNever`](https://github.com/sindresorhus/ts-extras/blob/main/source/assert-never.ts) from `ts-extras` over manual `const _: never = value` exhaustiveness checks.
+
+## Targeted pattern scope
+
+This rule only inspects single-declarator `const` statements where the declared identifier has a `never` type annotation.
+
+- `const _exhaustiveCheck: never = value;`
+- `const _: never = someExpression;`
+
+Named function calls, `throw` statements, and other exhaustiveness patterns are not matched.
+
+## What this rule reports
+
+This rule reports `const` declarations where the declared identifier is explicitly annotated with `never`, indicating a manual exhaustiveness check that can be replaced with `assertNever`.
+
+- Single-declarator `const` statements with a `never` type annotation.
+
+## Why this rule exists
+
+`assertNever(value)` is the canonical `ts-extras` utility for exhaustive-switch and discriminated-union coverage checks.
+
+- It is an explicit, searchable name for exhaustiveness enforcement.
+- It throws at runtime with a descriptive message if an unexpected value is encountered, unlike a silent `const _: never` declaration.
+- Standardizing the pattern ensures consistent behavior across the codebase — the silent-assignment form compiles away and provides no runtime safety.
+
+## ❌ Incorrect
+
+```ts
+const _exhaustiveCheck: never = fruit;
+```
+
+## ✅ Correct
+
+```ts
+import { assertNever } from "ts-extras";
+
+assertNever(fruit);
+```
+
+## Behavior and migration notes
+
+- `assertNever(value)` throws at runtime when called with a value. The manual `const _: never = value` pattern is a compile-time-only check that is silently removed after transpilation.
+- Applying the suggestion changes runtime semantics: unreachable branches will throw instead of silently passing. Verify the code path is truly unreachable before applying.
+- The rule provides a **suggestion** (not an autofix) because the runtime-behavior change must be reviewed manually.
+- Multi-declarator `const` statements (e.g., `const _a: never = a, _b: never = b`) are intentionally excluded.
+
+## ESLint flat config example
+
+```ts
+import typefest from "eslint-plugin-typefest";
+
+export default [
+    {
+        plugins: { typefest },
+        rules: {
+            "typefest/prefer-ts-extras-assert-never": "warn",
+        },
+    },
+];
+```
+
+## When not to use it
+
+Disable this rule if your codebase deliberately uses the `const _: never` pattern to avoid introducing runtime-throwing behavior in unreachable branches.
+
+## Package documentation
+
+ts-extras package documentation:
+
+Source file: [`source/assert-never.ts`](https://github.com/sindresorhus/ts-extras/blob/main/source/assert-never.ts)
+
+````ts
+/**
+Assert that the given value is `never`.
+
+This is useful to ensure that a `switch` statement or `if`-`else` chain is exhaustive — meaning that all possible cases are handled.
+
+An `assertNever` call is a compile-time type-check and will throw at runtime if the given value is not `never`.
+
+@example
+```
+import {assertNever} from 'ts-extras';
+
+type Fruit = 'apple' | 'banana' | 'cherry';
+
+function isYellow(fruit: Fruit): boolean {
+    switch (fruit) {
+        case 'apple':
+            return false;
+        case 'banana':
+            return true;
+        case 'cherry':
+            return false;
+        default:
+            assertNever(fruit);
+    }
+}
+```
+
+@category Type guard
+*/
+````
+
+> **Rule catalog ID:** R100
+
+## Further reading
+
+- [`ts-extras` README](https://github.com/sindresorhus/ts-extras)
+- [`ts-extras` package reference](https://www.npmjs.com/package/ts-extras)
+- [TypeScript Handbook: Narrowing](https://www.typescriptlang.org/docs/handbook/2/narrowing.html)

package/docs/rules/prefer-ts-extras-is-property-defined.md

@@ -0,0 +1,119 @@
+# prefer-ts-extras-is-property-defined
+
+Require [`isPropertyDefined`](https://github.com/sindresorhus/ts-extras/blob/main/source/is-property-defined.ts) from `ts-extras` in `Array.prototype.filter` callbacks instead of inline property-undefined checks.
+
+## Targeted pattern scope
+
+This rule only inspects inline `.filter(...)` predicates that perform an explicit `undefined` check against a single object property.
+
+- Inline property-undefined predicates inside `.filter(...)`, including:
+  - `filter((item) => item.prop !== undefined)`
+  - `filter((item) => undefined !== item.prop)`
+  - `filter((item) => item.prop != undefined)`
+  - `filter((item) => typeof item.prop !== "undefined")`
+
+Named predicate references, multi-argument callbacks, and broader callback logic are not matched unless they preserve this property-undefined-check shape.
+
+## What this rule reports
+
+This rule reports inline filter predicates that check whether a single object property is not `undefined` and can be normalized with `isPropertyDefined`.
+
+## Why this rule exists
+
+`filter(isPropertyDefined('prop'))` is the canonical `ts-extras` pattern for filtering out items where a specific property is `undefined`.
+
+- Filtering logic is consistent and composable across collections.
+- The property key is explicit in the function call, not hidden inside a callback.
+- Repeated inline `!== undefined` callback expressions are removed.
+- `isPropertyDefined` is a proper type predicate that narrows element types in the resulting array.
+
+## ❌ Incorrect
+
+```ts
+const named = users.filter((user) => user.name !== undefined);
+```
+
+## ✅ Correct
+
+```ts
+import { isPropertyDefined } from "ts-extras";
+
+const named = users.filter(isPropertyDefined("name"));
+```
+
+## Behavior and migration notes
+
+- `isPropertyDefined('prop')` checks `item[prop] !== undefined` and narrows the result type accordingly.
+- The autofix preserves the property name as a string literal.
+- Deep property access (e.g., `user.address.street !== undefined`) is intentionally excluded — only single-level property checks are flagged.
+- Computed property access (e.g., `user[key] !== undefined`) is intentionally excluded.
+
+## Additional examples
+
+### ❌ Incorrect — typeof form
+
+```ts
+const named = users.filter((user) => typeof user.name !== "undefined");
+```
+
+### ✅ Correct — typeof form fixed
+
+```ts
+const named = users.filter(isPropertyDefined("name"));
+```
+
+## ESLint flat config example
+
+```ts
+import typefest from "eslint-plugin-typefest";
+
+export default [
+    {
+        plugins: { typefest },
+        rules: {
+            "typefest/prefer-ts-extras-is-property-defined": "error",
+        },
+    },
+];
+```
+
+## When not to use it
+
+Disable this rule if your filter callbacks intentionally combine property checks with additional logic, or if the property name is dynamic.
+
+## Package documentation
+
+ts-extras package documentation:
+
+Source file: [`source/is-property-defined.ts`](https://github.com/sindresorhus/ts-extras/blob/main/source/is-property-defined.ts)
+
+````ts
+/**
+Returns a filter predicate that tests whether a given property key is defined (not `undefined`) on an object.
+
+This is useful as a type guard in `Array.prototype.filter` to narrow the resulting array type.
+
+@example
+```
+import {isPropertyDefined} from 'ts-extras';
+
+interface User {
+    name: string | undefined;
+}
+
+const users: User[] = [{ name: 'Alice' }, { name: undefined }];
+const namedUsers = users.filter(isPropertyDefined('name'));
+//=> [{ name: 'Alice' }]
+```
+
+@category Type guard
+*/
+````
+
+> **Rule catalog ID:** R101
+
+## Further reading
+
+- [`ts-extras` README](https://github.com/sindresorhus/ts-extras)
+- [`ts-extras` package reference](https://www.npmjs.com/package/ts-extras)
+- [TypeScript Handbook: Narrowing](https://www.typescriptlang.org/docs/handbook/2/narrowing.html)

package/docs/rules/prefer-ts-extras-is-property-present.md

@@ -0,0 +1,118 @@
+# prefer-ts-extras-is-property-present
+
+Require [`isPropertyPresent`](https://github.com/sindresorhus/ts-extras/blob/main/source/is-property-present.ts) from `ts-extras` in `Array.prototype.filter` callbacks instead of inline property-nullish checks.
+
+## Targeted pattern scope
+
+This rule only inspects inline `.filter(...)` predicates that perform an explicit loose-null check against a single object property.
+
+- Inline property-nullish predicates inside `.filter(...)`, including:
+  - `filter((item) => item.prop != null)`
+  - `filter((item) => null != item.prop)`
+
+Named predicate references, multi-argument callbacks, and stricter equality checks are not matched.
+
+## What this rule reports
+
+This rule reports inline filter predicates that check whether a single object property is not `null` (using loose equality, which also catches `undefined`) and can be normalized with `isPropertyPresent`.
+
+## Why this rule exists
+
+`filter(isPropertyPresent('prop'))` is the canonical `ts-extras` pattern for filtering out items where a specific property is `null` or `undefined`.
+
+- Filtering logic is consistent and composable across collections.
+- The property key is explicit in the function call, not embedded inside a callback expression.
+- Repeated inline `!= null` callback expressions are removed.
+- `isPropertyPresent` is a proper type predicate that narrows element types in the resulting array to exclude both `null` and `undefined`.
+
+## ❌ Incorrect
+
+```ts
+const titled = posts.filter((post) => post.title != null);
+```
+
+## ✅ Correct
+
+```ts
+import { isPropertyPresent } from "ts-extras";
+
+const titled = posts.filter(isPropertyPresent("title"));
+```
+
+## Behavior and migration notes
+
+- `isPropertyPresent('prop')` checks `item[prop] != null`, which is `true` when the value is neither `null` nor `undefined`.
+- The autofix preserves the property name as a string literal.
+- Strict null checks (e.g., `post.title !== null`) are intentionally excluded — those do not narrow away `undefined`.
+- Deep property access (e.g., `post.meta.title != null`) is intentionally excluded — only single-level property checks are flagged.
+- Computed property access (e.g., `post[key] != null`) is intentionally excluded.
+
+## Additional examples
+
+### ❌ Incorrect — reversed operands
+
+```ts
+const titled = posts.filter((post) => null != post.title);
+```
+
+### ✅ Correct — reversed operands fixed
+
+```ts
+const titled = posts.filter(isPropertyPresent("title"));
+```
+
+## ESLint flat config example
+
+```ts
+import typefest from "eslint-plugin-typefest";
+
+export default [
+    {
+        plugins: { typefest },
+        rules: {
+            "typefest/prefer-ts-extras-is-property-present": "error",
+        },
+    },
+];
+```
+
+## When not to use it
+
+Disable this rule if your filter callbacks intentionally combine property checks with additional logic, or if the property name is dynamic.
+
+## Package documentation
+
+ts-extras package documentation:
+
+Source file: [`source/is-property-present.ts`](https://github.com/sindresorhus/ts-extras/blob/main/source/is-property-present.ts)
+
+````ts
+/**
+Returns a filter predicate that tests whether a given property key is present (non-nullable) on an object.
+
+This is useful as a type guard in `Array.prototype.filter` to narrow the resulting array type by removing `null` and `undefined` property values.
+
+@example
+```
+import {isPropertyPresent} from 'ts-extras';
+
+interface Post {
+    title: string | null | undefined;
+}
+
+const posts: Post[] = [{ title: 'Hello' }, { title: null }];
+const titledPosts = posts.filter(isPropertyPresent('title'));
+//=> [{ title: 'Hello' }]
+```
+
+@category Type guard
+*/
+````
+
+> **Rule catalog ID:** R102
+
+## Further reading
+
+- [`ts-extras` README](https://github.com/sindresorhus/ts-extras)
+- [`ts-extras` package reference](https://www.npmjs.com/package/ts-extras)
+- [TypeScript Handbook: Narrowing](https://www.typescriptlang.org/docs/handbook/2/narrowing.html)

package/docs/rules/prefer-type-fest-absolute.md

@@ -0,0 +1,99 @@
+# prefer-type-fest-absolute
+
+Require TypeFest [`Absolute`](https://github.com/sindresorhus/type-fest/blob/main/source/absolute.d.ts) over common `Abs` or `AbsoluteValue` aliases.
+
+## Targeted pattern scope
+
+This rule reports `Abs<N>` and `AbsoluteValue<N>` type references and prefers the canonical `Absolute<N>` from type-fest for numeric absolute-value type computations.
+
+## What this rule reports
+
+- Type references named `Abs`.
+- Type references named `AbsoluteValue`.
+
+### Detection boundaries
+
+- ✅ Reports direct `Abs<N>` and `AbsoluteValue<N>` type references.
+- ✅ Autofixes by renaming the identifier to `Absolute` and inserting a `type-fest` import when absent.
+- ❌ Does not auto-fix where the `Absolute` identifier is shadowed by a type parameter in scope.
+
+## Why this rule exists
+
+`Absolute<N>` is the canonical TypeFest utility for computing the absolute value of a numeric literal type.
+
+Using a consistent name across a codebase avoids confusion between locally-defined `Abs` helpers and the standard TypeFest utility. A single canonical name also makes the intent immediately readable by contributors familiar with type-fest.
+
+## ❌ Incorrect
+
+```ts
+type Result = Abs<-5>;
+type Other = AbsoluteValue<-100>;
+```
+
+## ✅ Correct
+
+```ts
+import type { Absolute } from "type-fest";
+
+type Result = Absolute<-5>;
+type Other = Absolute<-100>;
+```
+
+## Behavior and migration notes
+
+- `Absolute<N>` strips the leading minus sign from a negative numeric literal type, producing the non-negative form.
+- Locally-defined `Abs` or `AbsoluteValue` helpers may have different semantics (e.g., different constraints). Verify the behavior is equivalent before applying the autofix.
+- The autofix is safe to apply when the local alias is a mere re-export or thin wrapper over `Absolute`.
+
+## ESLint flat config example
+
+```ts
+import typefest from "eslint-plugin-typefest";
+
+export default [
+    {
+        plugins: { typefest },
+        rules: {
+            "typefest/prefer-type-fest-absolute": "error",
+        },
+    },
+];
+```
+
+## When not to use it
+
+Disable this rule if your codebase intentionally standardizes `Abs` or `AbsoluteValue` naming, or if your local alias provides additional constraints not present in the TypeFest utility.
+
+## Package documentation
+
+TypeFest package documentation:
+
+Source file: [`source/absolute.d.ts`](https://github.com/sindresorhus/type-fest/blob/main/source/absolute.d.ts)
+
+````ts
+/**
+Returns the absolute value of a given integer type.
+
+@example
+```
+import type {Absolute} from 'type-fest';
+
+type SomeValue = Absolute<-1>;
+//=> 1
+```
+
+@category Numeric
+*/
+````
+
+> **Rule catalog ID:** R097
+
+## Further reading
+
+- [TypeFest README](https://github.com/sindresorhus/type-fest)
+- [TypeScript Handbook: Utility Types](https://www.typescriptlang.org/docs/handbook/utility-types.html)
+
+## Adoption resources
+
+- [Rule adoption checklist](./guides/adoption-checklist.md)
+- [Rollout and fix safety](./guides/rollout-and-fix-safety.md)

package/docs/rules/prefer-type-fest-non-nullable-deep.md

@@ -0,0 +1,105 @@
+# prefer-type-fest-non-nullable-deep
+
+Require TypeFest [`NonNullableDeep`](https://github.com/sindresorhus/type-fest/blob/main/source/non-nullable-deep.d.ts) over `DeepNonNullable` aliases.
+
+## Targeted pattern scope
+
+This rule reports `DeepNonNullable<T>` type references and prefers the canonical `NonNullableDeep<T>` from type-fest for recursive non-nullable transformations.
+
+## What this rule reports
+
+- Type references named `DeepNonNullable`.
+
+### Detection boundaries
+
+- ✅ Reports direct `DeepNonNullable<T>` type references.
+- ✅ Autofixes by renaming the identifier to `NonNullableDeep` and inserting a `type-fest` import when absent.
+- ❌ Does not auto-fix where the `NonNullableDeep` identifier is shadowed by a type parameter in scope.
+
+## Why this rule exists
+
+`NonNullableDeep<T>` is the canonical TypeFest utility for recursively removing `null` and `undefined` from all nested properties.
+
+Using a consistent name avoids confusion between locally-defined deep-non-nullable helpers and the official TypeFest utility. The canonical name also communicates intent to contributors familiar with type-fest.
+
+## ❌ Incorrect
+
+```ts
+type StrictConfig = DeepNonNullable<Config>;
+```
+
+## ✅ Correct
+
+```ts
+import type { NonNullableDeep } from "type-fest";
+
+type StrictConfig = NonNullableDeep<Config>;
+```
+
+## Behavior and migration notes
+
+- `NonNullableDeep<T>` recursively removes `null` and `undefined` from all nested object properties.
+- Validate parity if your legacy `DeepNonNullable` alias had different behavior for arrays, maps, or sets.
+- Prefer explicit narrowing over deep non-nullable transformation where the required shape is known at the call site.
+
+## ESLint flat config example
+
+```ts
+import typefest from "eslint-plugin-typefest";
+
+export default [
+    {
+        plugins: { typefest },
+        rules: {
+            "typefest/prefer-type-fest-non-nullable-deep": "error",
+        },
+    },
+];
+```
+
+## When not to use it
+
+Disable this rule if your codebase intentionally standardizes `DeepNonNullable` naming or if your local alias provides additional constraints not present in the TypeFest utility.
+
+## Package documentation
+
+TypeFest package documentation:
+
+Source file: [`source/non-nullable-deep.d.ts`](https://github.com/sindresorhus/type-fest/blob/main/source/non-nullable-deep.d.ts)
+
+````ts
+/**
+Deeply remove `null` and `undefined` from all properties of `T`.
+
+Use-cases:
+- Removing optional and nullable markers after a data-hydration step.
+- Ensuring a configuration object has all required values present.
+
+@example
+```
+import type {NonNullableDeep} from 'type-fest';
+
+interface Config {
+    host: string | null;
+    port: number | undefined;
+}
+
+type StrictConfig = NonNullableDeep<Config>;
+// => { host: string; port: number }
+```
+
+@category Object
+*/
+````
+
+> **Rule catalog ID:** R098
+
+## Further reading
+
+- [TypeFest README](https://github.com/sindresorhus/type-fest)
+- [TypeScript Handbook: Utility Types](https://www.typescriptlang.org/docs/handbook/utility-types.html)
+
+## Adoption resources
+
+- [Rule adoption checklist](./guides/adoption-checklist.md)
+- [Rollout and fix safety](./guides/rollout-and-fix-safety.md)