eslint-plugin-nextfriday 3.2.1 → 4.1.0

package/docs/rules/PREFER_INTERFACE_FOR_COMPONENT_PROPS.md

@@ -0,0 +1,53 @@
+# prefer-interface-for-component-props
+
+Enforce `interface` over `type` alias for component prop declarations in component files (`*.tsx`, `*.jsx`).
+
+> This rule is auto-fixable using `--fix`.
+
+## Rule Details
+
+In component files, prop declarations are more idiomatic as `interface` than `type` aliases. Interfaces support declaration merging, are easier to extend, and produce clearer error messages from the TypeScript compiler. This rule converts `type` aliases that look like component prop types into `interface` declarations.
+
+The rule fires only when all of the following are true:
+
+- The file extension is `.tsx` or `.jsx`
+- The declaration is a `type` alias whose name ends with `Props`
+- The body of the type is an object literal (`{ ... }`)
+
+Type aliases with intersection types (`type FooProps = Other & { x: number }`), union types (`type Variant = 'a' | 'b'`), or non-object bodies (`type Props = ReactNode`) are left alone — they cannot be expressed as a single interface without restructuring.
+
+## Examples
+
+### Incorrect
+
+```tsx
+type StorePopoverProps = {
+  trigger: ReactNode;
+};
+
+const StorePopover = (props: Readonly<StorePopoverProps>) => {
+  return <div>{props.trigger}</div>;
+};
+```
+
+### Correct
+
+```tsx
+interface StorePopoverProps {
+  trigger: ReactNode;
+}
+
+const StorePopover = (props: Readonly<StorePopoverProps>) => {
+  return <div>{props.trigger}</div>;
+};
+```
+
+## When Not To Use It
+
+- If your codebase uses `type` aliases for component props by convention
+- If you rely on type alias features that interfaces don't support (for example, intersections or unions in the same declaration)
+
+## Related Rules
+
+- [enforce-props-suffix](./ENFORCE_PROPS_SUFFIX.md) - Enforces the `Props` suffix that this rule keys off
+- [prefer-interface-over-inline-types](./PREFER_INTERFACE_OVER_INLINE_TYPES.md) - Sister rule for inline types in component params

package/docs/rules/PREFER_NAMED_PARAM_TYPES.md

@@ -89,6 +89,10 @@ const setup = (config: Config) => {
 };
 ```
 
+## Exceptions
+
+This rule defers to [`prefer-interface-over-inline-types`](./PREFER_INTERFACE_OVER_INLINE_TYPES.md) for React components with a single non-destructured prop parameter (for example, `function Comp(props: { name: string }) { return <div /> }`). Both rules would otherwise report the same parameter with different messages, so `prefer-named-param-types` skips that case and lets the React-specific rule produce the canonical message. Destructured component props (`function Comp({ name }: { name: string })`) and non-component functions are still reported here.
+
 ## When Not To Use It
 
 - If you prefer inline types for simple, one-off function parameters
@@ -97,4 +101,4 @@ const setup = (config: Config) => {
 
 ## Related Rules
 
-- [prefer-interface-over-inline-types](./PREFER_INTERFACE_OVER_INLINE_TYPES.md) - Similar rule focused on React component props with complexity criteria
+- [prefer-interface-over-inline-types](./PREFER_INTERFACE_OVER_INLINE_TYPES.md) - Owns React component non-destructured prop case

package/docs/rules/PREFER_PROPS_WITH_CHILDREN.md

@@ -0,0 +1,112 @@
+# prefer-props-with-children
+
+Prefer `PropsWithChildren<T>` over manually declaring `children: ReactNode` in component props.
+
+## Rule Details
+
+This rule reports interfaces, type aliases, and inline parameter types that declare a `children` field typed as `ReactNode` (or `React.ReactNode`). React already provides the `PropsWithChildren<T>` helper for this exact case, so prefer it for consistency and to avoid restating the well-known `children` shape on every component.
+
+The rule only flags `children` whose type is exactly `ReactNode` (matching what `PropsWithChildren` provides). Other shapes such as `ReactElement`, render-prop functions, or unions like `ReactNode | string` are left alone.
+
+### Why?
+
+- `PropsWithChildren<T>` is the canonical type for components that accept children, making intent obvious at a glance.
+- It eliminates duplication of the `children` declaration across every component that accepts children.
+- It keeps the surrounding props focused on what is unique to the component.
+
+## Examples
+
+### Incorrect
+
+```tsx
+interface LayoutProps {
+  children: ReactNode;
+}
+```
+
+```tsx
+interface CardProps {
+  title: string;
+  children: ReactNode;
+}
+```
+
+```tsx
+interface OptionalChildrenProps {
+  children?: ReactNode;
+  label: string;
+}
+```
+
+```tsx
+interface ReactNamespaceProps {
+  children: React.ReactNode;
+}
+```
+
+```tsx
+type WrapperProps = {
+  children: ReactNode;
+  className: string;
+};
+```
+
+```tsx
+const Component = ({ children, label }: { children: ReactNode; label: string }) => (
+  <div>
+    {children}
+    {label}
+  </div>
+);
+```
+
+### Correct
+
+```tsx
+type LayoutProps = PropsWithChildren;
+```
+
+```tsx
+interface CardProps extends PropsWithChildren {
+  title: string;
+}
+```
+
+```tsx
+type WrapperProps = PropsWithChildren<{
+  className: string;
+}>;
+```
+
+```tsx
+const Component = (props: Readonly<PropsWithChildren<{ label: string }>>) => (
+  <div>
+    {props.children}
+    {props.label}
+  </div>
+);
+```
+
+```tsx
+interface RenderProps {
+  children: (value: string) => ReactNode;
+}
+```
+
+```tsx
+interface SlotProps {
+  children: ReactElement;
+}
+```
+
+## When Not To Use It
+
+This rule should not be used if:
+
+- Your project intentionally avoids `PropsWithChildren` and prefers explicit `children` declarations.
+- You frequently use children types other than `ReactNode` (this rule already skips those cases).
+
+## Related Rules
+
+- [`prefer-react-import-types`](./PREFER_REACT_IMPORT_TYPES.md) - Enforce direct imports from `react` instead of `React.X`
+- [`enforce-props-suffix`](./ENFORCE_PROPS_SUFFIX.md) - Enforce `Props` suffix for component prop types