eslint-plugin-nextfriday 4.3.2 → 5.0.0

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "eslint-plugin-nextfriday",
-  "version": "4.3.2",
+  "version": "5.0.0",
   "description": "A comprehensive ESLint plugin providing custom rules and configurations for Next Friday development workflows.",
   "keywords": [
     "eslint",

package/docs/rules/ENFORCE_CAMEL_CASE.md

@@ -1,68 +0,0 @@
-# enforce-camel-case
-
-Enforce camelCase for variables and functions, ban snake_case, and restrict PascalCase to React components.
-
-## Rule Details
-
-This rule enforces consistent naming conventions across your codebase:
-
-- Variables and functions must use camelCase
-- snake_case is banned for all variable and function declarations
-- PascalCase is reserved exclusively for React components (functions that return JSX)
-
-Global static constants are not checked by this rule. Use `enforce-constant-case` for those.
-
-### Why?
-
-Consistent naming conventions reduce cognitive load. When PascalCase is reserved for components and camelCase is used for everything else, the name alone tells you what something is.
-
-## Examples
-
-### Incorrect
-
-```ts
-// snake_case variables
-let current_index = 0;
-const first_name = "John";
-
-// snake_case functions
-function calculate_total() {
-  return 0;
-}
-
-// PascalCase for non-component functions
-const CalculateTotal = () => 0;
-const FormatDate = (date: string) => date;
-```
-
-### Correct
-
-```ts
-// camelCase variables
-let currentIndex = 0;
-const firstName = "John";
-
-// camelCase functions
-function calculateTotal() { return 0; }
-const formatDate = (date: string) => date;
-
-// PascalCase for React components
-const ArticleCard = () => <div />;
-const WrappedComponent = memo(() => <div />);
-const LazyPage = lazy(() => import("./Page"));
-```
-
-## Exceptions
-
-- Global static constants (handled by `enforce-constant-case`)
-- SCREAMING_SNAKE_CASE variables (handled by `no-misleading-constant-case`)
-- React components wrapped with `memo`, `forwardRef`, or `lazy`
-
-## When Not To Use It
-
-If your project does not follow the convention that PascalCase is reserved for React components.
-
-## Related Rules
-
-- [enforce-constant-case](ENFORCE_CONSTANT_CASE.md) - Enforces SCREAMING_SNAKE_CASE for global static constants
-- [no-misleading-constant-case](NO_MISLEADING_CONSTANT_CASE.md) - Disallows SCREAMING_SNAKE_CASE in local scope

package/docs/rules/ENFORCE_PROPERTY_CASE.md

@@ -1,63 +0,0 @@
-# enforce-property-case
-
-Enforce camelCase for unquoted object property keys.
-
-## Rule Details
-
-This rule bans snake_case and SCREAMING_SNAKE_CASE for unquoted object property keys. Quoted keys (string literals) are allowed for API boundaries where external systems require different conventions.
-
-### Why?
-
-Object properties should follow the same camelCase convention as variables. When an external API requires snake_case keys, wrapping them in quotes makes it explicit that the naming is intentional and driven by an external contract.
-
-## Examples
-
-### Incorrect
-
-```ts
-const userPayload = {
-  first_name: "John",
-  last_name: "Doe",
-};
-
-const item = {
-  ITEM_ID: 1,
-};
-```
-
-### Correct
-
-```ts
-// camelCase properties
-const userPayload = {
-  firstName: "John",
-  lastName: "Doe",
-};
-
-// Quoted keys for API boundaries
-const apiPayload = {
-  first_name: "John",
-  last_name: "Doe",
-};
-
-// as const objects are exempt (enum-like pattern)
-const STATUS_MAP = {
-  ACTIVE: "active",
-  INACTIVE: "inactive",
-} as const;
-```
-
-## Exceptions
-
-- Quoted property keys (`"first_name"`) are always allowed
-- Computed property keys (`[key]`) are not checked
-- Properties inside `as const` objects and arrays are exempt
-
-## When Not To Use It
-
-If your project frequently uses snake_case or SCREAMING_SNAKE_CASE for object properties without quoting.
-
-## Related Rules
-
-- [enforce-camel-case](ENFORCE_CAMEL_CASE.md) - Enforces camelCase for variables and functions
-- [enforce-constant-case](ENFORCE_CONSTANT_CASE.md) - Enforces SCREAMING_SNAKE_CASE for global constants

package/docs/rules/NO_INLINE_DEFAULT_EXPORT.md

@@ -1,97 +0,0 @@
-# no-inline-default-export
-
-Disallow inline exports. Declare first, then export separately.
-
-## Rule Details
-
-This rule enforces separating declarations from exports. Instead of `export function`, declare the function first, then export it.
-
-## Examples
-
-### Incorrect
-
-```ts
-// Inline named export
-export function fetchData() {
-  return fetch("/api");
-}
-
-// Inline async named export
-export async function fetchHighlight(id: string) {
-  return await api.get(`/highlights/${id}`);
-}
-
-// Inline class export
-export class UserService {
-  // ...
-}
-
-// Inline default export
-export default function generator() {
-  // ...
-}
-
-// Inline default class export
-export default class MyService {
-  // ...
-}
-
-// Anonymous exports
-export default function () {
-  return "anonymous";
-}
-
-export default () => "arrow";
-```
-
-### Correct
-
-```ts
-// Declare function, then export
-function fetchData() {
-  return fetch("/api");
-}
-
-export { fetchData };
-
-// Declare async function, then export
-async function fetchHighlight(id: string) {
-  return await api.get(`/highlights/${id}`);
-}
-
-export { fetchHighlight };
-
-// Or use default export
-export default fetchHighlight;
-
-// Declare class, then export
-class UserService {
-  // ...
-}
-
-export { UserService };
-
-// Declare function, then default export
-function generator() {
-  // ...
-}
-
-export default generator;
-
-// Re-exports are allowed
-export { foo } from "./foo";
-export { bar as default } from "./bar";
-export type { Baz } from "./baz";
-
-// Literals and objects are allowed
-export default "literal";
-export default { key: "value" };
-```
-
-## When Not To Use It
-
-If your project prefers inline exports for brevity, you may want to disable this rule.
-
-## Related Rules
-
-- [prefer-function-declaration](./PREFER_FUNCTION_DECLARATION.md) - Prefer function declarations over arrow functions

package/docs/rules/NO_NESTED_TERNARY.md

@@ -1,45 +0,0 @@
-# no-nested-ternary
-
-Disallow nested ternary expressions.
-
-## Rule Details
-
-Nested ternary expressions are difficult to read and understand. This rule enforces using functions with early returns instead.
-
-## Examples
-
-### Incorrect
-
-```ts
-const status = isLoading ? "loading" : isError ? "error" : "success";
-
-const value = a ? (b ? 1 : 2) : 3;
-
-const result = condition1 ? value1 : condition2 ? value2 : condition3 ? value3 : defaultValue;
-```
-
-### Correct
-
-```ts
-// Simple ternary (no nesting)
-const status = isLoading ? "loading" : "success";
-
-// Function with early returns
-const getStatus = () => {
-  if (isLoading) return "loading";
-  if (isError) return "error";
-  return "success";
-};
-
-// IIFE for inline usage
-const status = (() => {
-  if (isLoading) return "loading";
-  if (isError) return "error";
-  return "success";
-})();
-```
-
-## When Not To Use It
-
-- If your team prefers nested ternaries for simple cases
-- If you have existing code with many nested ternaries and don't want to refactor

package/docs/rules/NO_REDUNDANT_FRAGMENT.md

@@ -1,56 +0,0 @@
-# no-redundant-fragment
-
-Disallow Fragments that wrap zero or one child.
-
-## Rule Details
-
-This rule flags Fragments (`<>...</>`, `<Fragment>...</Fragment>`, `<React.Fragment>...</React.Fragment>`) that wrap zero or one child. A Fragment is only justified when grouping multiple sibling nodes, or when a `key` prop is required during list iteration.
-
-A Fragment with a single child is structurally equivalent to that child alone. An empty Fragment renders nothing and adds noise to the source.
-
-### Why?
-
-- **Source clarity**: A Fragment around a single child is dead syntax — it tells the reader nothing.
-- **Less noise in the AST**: Devtools, search, and codemods do not have to step over an extra layer.
-- **Forces a decision**: Either the children are siblings (Fragment is the right tool) or they are not (drop it).
-
-## Examples
-
-### Incorrect
-
-```tsx
-<></>
-<>{x}</>
-<><A /></>
-<>text</>
-<Fragment>x</Fragment>
-<React.Fragment>{x}</React.Fragment>
-<React.Fragment></React.Fragment>
-```
-
-### Correct
-
-```tsx
-<>{a}{b}</>
-<><A /><B /></>
-<Fragment>{a}{b}</Fragment>
-<React.Fragment>{a}{b}</React.Fragment>
-
-// key is the legitimate reason to use long-form Fragment:
-<React.Fragment key={item.id}>{item.label}{item.value}</React.Fragment>
-<Fragment key={k}>{x}</Fragment>
-```
-
-## What This Rule Checks
-
-A Fragment is flagged when its meaningful children count is `0` or `1`. JSX text nodes that contain only whitespace are not counted as children.
-
-The rule does not fire on a long-form Fragment (`<Fragment>` or `<React.Fragment>`) that carries a `key` attribute — `key` is the canonical reason long-form Fragment exists, since the shorthand `<>...</>` cannot accept attributes.
-
-## When Not To Use It
-
-If your codebase uses single-child Fragments to keep diffs stable around conditionally-rendered siblings, or if you rely on a build-time transform that depends on the Fragment wrapper.
-
-## Related Rules
-
-- [no-ghost-wrapper](NO_GHOST_WRAPPER.md)

package/docs/rules/NO_SINGLE_CHAR_VARIABLES.md

@@ -1,98 +0,0 @@
-# no-single-char-variables
-
-Disallow single character variable and parameter names for better code readability.
-
-## Rule Details
-
-This rule enforces descriptive variable and parameter names by disallowing single character identifiers. Single character names like `d`, `u`, `l`, `r` are cryptic and make code harder to understand. They require readers to guess or track what each variable represents.
-
-## Examples
-
-### Incorrect
-
-```ts
-const d = new Date();
-const u = await getUser();
-const l = list.length;
-const r = await fetch(url);
-
-users.map((u) => u.id);
-onClick((e) => e.preventDefault());
-
-const add = (a, b) => a + b;
-const e = (x) => x * 2;
-
-function f() {
-  return 1;
-}
-
-const { a } = obj;
-const [x] = array;
-
-try {
-} catch (e) {}
-```
-
-### Correct
-
-```ts
-const currentDate = new Date();
-const currentUser = await getUser();
-const itemCount = list.length;
-const response = await fetch(url);
-
-users.map((user) => user.id);
-onClick((event) => event.preventDefault());
-
-const add = (val1, val2) => val1 + val2;
-const add = (width, height) => width * height;
-const calculateDouble = (value) => value * 2;
-
-function getName() {
-  return "test";
-}
-
-const { alpha } = obj;
-const { a: alpha } = obj;
-const [first] = array;
-
-try {
-} catch (error) {}
-```
-
-## Exceptions
-
-The rule allows the following exceptions:
-
-### Loop Counters
-
-Single character loop counters `i`, `j`, `k`, `n` are allowed in traditional for loops:
-
-```ts
-for (let i = 0; i < 10; i++) {}
-for (let j = 0; j < items.length; j++) {}
-for (let i = 0, j = 10; i < j; i++, j--) {}
-```
-
-Note: These are only allowed in traditional `for` loops, not in `for...of` or `for...in` loops.
-
-### Underscore for Unused Variables
-
-A single underscore `_` is allowed to indicate intentionally unused variables:
-
-```ts
-const _ = unusedValue;
-const [_, second] = array;
-array.map((_, index) => index);
-```
-
-## When Not To Use It
-
-- For very short scripts or throwaway code
-- When working with mathematical formulas where single letters are conventional (e.g., `x`, `y` for coordinates)
-- In legacy codebases where this pattern is established and changing would be disruptive
-
-## Related Rules
-
-- [prefer-destructuring-params](./PREFER_DESTRUCTURING_PARAMS.md) - Encourages destructuring for function parameters
-- [prefer-named-param-types](./PREFER_NAMED_PARAM_TYPES.md) - Encourages named parameters for better readability

package/docs/rules/PREFER_FUNCTION_DECLARATION.md

@@ -1,118 +0,0 @@
-# prefer-function-declaration
-
-Enforce function declarations over arrow functions assigned to variables in `.ts` files.
-
-## Rule Details
-
-This rule requires using function declarations instead of arrow functions or function expressions when defining named functions. Arrow functions used as callbacks are still allowed.
-
-**Target:** `.ts` files only (not `.tsx`, `.js`, or `.d.ts`)
-
-## Examples
-
-### Incorrect
-
-```ts
-// Arrow function assigned to variable
-const formatDate = (date: Date) => {
-  return date.toLocaleDateString("th-TH");
-};
-
-// Arrow function with implicit return
-const add = (a: number, b: number) => a + b;
-
-// Function expression assigned to variable
-const greet = function (name: string) {
-  return `Hello ${name}`;
-};
-
-// Async arrow function
-const fetchUser = async (id: string) => {
-  return await api.get(`/users/${id}`);
-};
-```
-
-### Correct
-
-```ts
-// Function declaration
-function formatDate(date: Date) {
-  return date.toLocaleDateString("th-TH");
-}
-
-// Function declaration
-function add(a: number, b: number) {
-  return a + b;
-}
-
-// Function declaration
-function greet(name: string) {
-  return `Hello ${name}`;
-}
-
-// Async function declaration
-async function fetchUser(id: string) {
-  return await api.get(`/users/${id}`);
-}
-```
-
-## What This Rule Allows
-
-Arrow functions are still allowed in the following contexts:
-
-### Callbacks
-
-```ts
-const years = dates.map((date) => date.getFullYear());
-const active = items.filter((item) => item.active);
-const sorted = items.sort((a, b) => a.name.localeCompare(b.name));
-items.forEach((item) => console.log(item));
-setTimeout(() => console.log("done"), 1000);
-```
-
-### Object Properties
-
-```ts
-const handler = {
-  onClick: () => console.log("clicked"),
-  onHover: () => setHovered(true),
-};
-```
-
-### Array Elements
-
-```ts
-const callbacks = [() => 1, () => 2, () => 3];
-```
-
-### Return Values
-
-```ts
-function createHandler() {
-  return () => console.log("handled");
-}
-```
-
-### Conditional/Logical Expressions
-
-```ts
-const fn = condition ? () => valueA : () => valueB;
-const handler = defaultFn || (() => fallback);
-```
-
-### TSX Files
-
-```ts
-// components/Button.tsx - Arrow functions allowed
-const Button = () => <button>Click me</button>;
-```
-
-## When Not To Use It
-
-- When you prefer arrow functions for all function definitions
-- In projects where arrow function style is established
-- When you need lexical `this` binding
-
-## Related Rules
-
-- [no-inline-default-export](./NO_INLINE_DEFAULT_EXPORT.md) - Disallow inline exports

package/docs/rules/PREFER_INLINE_TYPE_EXPORT.md

@@ -1,64 +0,0 @@
-# prefer-inline-type-export
-
-Require type and interface declarations to be exported inline rather than via a separate export statement.
-
-> This rule is auto-fixable using `--fix`.
-
-## Rule Details
-
-This rule enforces that `interface` and `type` declarations are exported directly at the declaration site using the `export` keyword, rather than being exported separately via `export type { ... }` or `export { ... }` at the bottom of the file.
-
-### Why?
-
-Inline exports make it immediately clear at the declaration site that a type is part of the module's public API. Separate export statements create a disconnect between the declaration and its visibility, making it harder to understand the module's surface area at a glance.
-
-## Examples
-
-### Incorrect
-
-```ts
-interface ButtonProps {
-  label: string;
-  disabled: boolean;
-}
-
-type Theme = "light" | "dark";
-
-export type { ButtonProps, Theme };
-```
-
-```ts
-interface Config {
-  port: number;
-}
-
-export { Config };
-```
-
-### Correct
-
-```ts
-export interface ButtonProps {
-  label: string;
-  disabled: boolean;
-}
-
-export type Theme = "light" | "dark";
-```
-
-```ts
-export interface Config {
-  port: number;
-}
-```
-
-## Exceptions
-
-This rule only applies to `interface` and `type` declarations defined in the same file. It does not flag:
-
-- Re-exports from other modules (`export type { Foo } from './types'`)
-- Separate exports of non-type declarations (variables, functions, classes)
-
-## When Not To Use It
-
-If your project prefers grouping all exports at the bottom of the file for consistency.

package/docs/rules/PREFER_JSX_TEMPLATE_LITERALS.md

@@ -1,80 +0,0 @@
-# prefer-jsx-template-literals
-
-Enforce using template literals instead of mixing text and JSX expressions.
-
-> This rule is auto-fixable using `--fix`.
-
-## Rule Details
-
-This rule prevents mixing plain text with JSX expressions in JSX elements, which can lead to incorrect spacing and readability issues. Instead, it enforces using template literals to combine text and expressions.
-
-### Why?
-
-Mixing text and JSX expressions without proper spacing can cause:
-
-1. **Spacing issues**: `<div>+ {value}</div>` renders as "+ value" with unexpected spacing
-2. **Inconsistent formatting**: Hard to maintain consistent spacing across the codebase
-3. **Readability problems**: Mixed syntax makes code harder to read and understand
-
-Using template literals ensures:
-
-- Explicit control over spacing
-- Consistent formatting
-- Better readability
-- Easier to maintain
-
-## Examples
-
-### Incorrect
-
-```tsx
-// Bad: Text followed by expression
-<div>+ {fooVariable}</div>
-<div>+{fooVariable}</div>
-<div>Price: {price}</div>
-<div>$ {amount}</div>
-<span>Total: {total}</span>
-<p>Hello {name}</p>
-
-// Bad: Expression followed by text
-<div>{count} items</div>
-<div>{price}$</div>
-```
-
-### Correct
-
-```tsx
-// Good: Using template literals
-<div>{`+${fooVariable}`}</div>
-<div>{`+ ${fooVariable}`}</div>
-<div>{`Price: ${price}`}</div>
-<div>{`$ ${amount}`}</div>
-<span>{`Total: ${total}`}</span>
-<p>{`Hello ${name}`}</p>
-
-// Good: Using template literals for expression + text
-<div>{`${count}items`}</div>
-<div>{`${price}$`}</div>
-
-// Good: Expression only
-<div>{fooVariable}</div>
-<div>{price}</div>
-
-// Good: Text only
-<div>Some static text</div>
-
-// Good: Expression with whitespace only around it
-<div>  {fooVariable}  </div>
-<div>
-  {fooVariable}
-</div>
-```
-
-## When Not To Use It
-
-If you prefer mixing text and JSX expressions, you can disable this rule. However, this may lead to inconsistent spacing and formatting issues.
-
-## Further Reading
-
-- [Template Literals (MDN)](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Template_literals)
-- [JSX in React](https://react.dev/learn/writing-markup-with-jsx)