eslint-plugin-nextfriday 1.5.3 → 1.6.0

package/CHANGELOG.md

@@ -1,5 +1,14 @@
 # eslint-plugin-nextfriday
 
+## 1.6.0
+
+### Minor Changes
+
+- [#36](https://github.com/next-friday/eslint-plugin-nextfriday/pull/36) [`f819ffa`](https://github.com/next-friday/eslint-plugin-nextfriday/commit/f819ffa8eed179e38eed4ec51a05dec53dd979d0) Thanks [@joetakara](https://github.com/joetakara)! - Add three new ESLint rules:
+  - `jsx-no-non-component-function`: Prevent non-component functions at top level in .tsx/.jsx files
+  - `enforce-sorted-destructuring`: Enforce alphabetical sorting of destructured properties with defaults first
+  - `jsx-no-variable-in-callback`: Prevent variable declarations inside JSX callbacks for cleaner code
+
 ## 1.5.3
 
 ### Patch Changes

package/README.md

@@ -118,12 +118,16 @@ module.exports = {
 | [md-filename-case-restriction](docs/rules/MD_FILENAME_CASE_RESTRICTION.md)             | Enforce SNAKE_CASE filenames for .md files                                    | ❌      |
 | [prefer-destructuring-params](docs/rules/PREFER_DESTRUCTURING_PARAMS.md)               | Enforce destructuring for functions with multiple parameters                  | ❌      |
 | [no-explicit-return-type](docs/rules/NO_EXPLICIT_RETURN_TYPE.md)                       | Disallow explicit return types on functions                                   | ✅      |
+| [jsx-no-non-component-function](docs/rules/JSX_NO_NON_COMPONENT_FUNCTION.md)           | Disallow non-component functions at top level in .tsx and .jsx files          | ❌      |
+| [jsx-no-variable-in-callback](docs/rules/JSX_NO_VARIABLE_IN_CALLBACK.md)               | Disallow variable declarations inside callback functions within JSX           | ❌      |
 | [prefer-import-type](docs/rules/PREFER_IMPORT_TYPE.md)                                 | Enforce using 'import type' for type-only imports                             | ✅      |
 | [prefer-named-param-types](docs/rules/PREFER_NAMED_PARAM_TYPES.md)                     | Enforce named types for function parameters with object types                 | ❌      |
 | [prefer-interface-over-inline-types](docs/rules/PREFER_INTERFACE_OVER_INLINE_TYPES.md) | Enforce interface declarations over inline types for React props              | ❌      |
+| [prefer-jsx-template-literals](docs/rules/PREFER_JSX_TEMPLATE_LITERALS.md)             | Enforce using template literals instead of mixing text and JSX expressions    | ✅      |
 | [prefer-react-import-types](docs/rules/PREFER_REACT_IMPORT_TYPES.md)                   | Enforce direct imports from 'react' instead of React.X                        | ✅      |
 | [react-props-destructure](docs/rules/REACT_PROPS_DESTRUCTURE.md)                       | Enforce destructuring props inside React component body                       | ❌      |
 | [enforce-readonly-component-props](docs/rules/ENFORCE_READONLY_COMPONENT_PROPS.md)     | Enforce Readonly wrapper for React component props                            | ✅      |
+| [enforce-sorted-destructuring](docs/rules/ENFORCE_SORTED_DESTRUCTURING.md)             | Enforce alphabetical sorting of destructured properties with defaults first   | ❌      |
 | [no-complex-inline-return](docs/rules/NO_COMPLEX_INLINE_RETURN.md)                     | Disallow complex inline expressions in return statements - prefer const first | ❌      |
 | [no-logic-in-params](docs/rules/NO_LOGIC_IN_PARAMS.md)                                 | Disallow logic or conditions in function parameters - extract to const first  | ❌      |
 | [no-env-fallback](docs/rules/NO_ENV_FALLBACK.md)                                       | Disallow fallback values for environment variables as they can be dangerous   | ❌      |

package/docs/rules/ENFORCE_SORTED_DESTRUCTURING.md

@@ -0,0 +1,122 @@
+# enforce-sorted-destructuring
+
+Enforce alphabetical sorting of destructured properties with defaults first.
+
+## Rule Details
+
+This rule enforces that object destructuring properties are sorted alphabetically, with properties that have default values coming first. Default values are further sorted by type (string, number, boolean, object) and then alphabetically within each type.
+
+### Why?
+
+1. **Consistency**: Alphabetical ordering makes code more predictable and easier to scan
+2. **Readability**: Sorted properties are easier to find in large destructuring statements
+3. **Organization**: Grouping defaults first keeps the destructuring organized by intent
+4. **Maintainability**: Clear structure makes it easier to add or remove properties
+
+### Sorting Order
+
+Properties are sorted in this order:
+
+1. **Properties with defaults** (sorted by type, then alphabetically):
+   - String defaults (alphabetically)
+   - Number defaults (alphabetically)
+   - Boolean defaults (alphabetically)
+   - Object/Array defaults (alphabetically)
+   - Other defaults (alphabetically)
+
+2. **Properties without defaults** (alphabetically)
+
+## Examples
+
+### ❌ Incorrect
+
+```js
+// Bad: Not sorted alphabetically
+const { d, b, a, c } = foo;
+```
+
+```js
+// Bad: Completely unsorted
+const { z, a, m } = foo;
+```
+
+```js
+// Bad: Default in the middle (should be first)
+const { a, b, d = "string", c } = foo;
+```
+
+```js
+// Bad: Non-default before defaults
+const { a, d = "string", e = 0 } = foo;
+```
+
+```js
+// Bad: Defaults not sorted by type (number before string)
+const { e = 0, d = "string", a, b } = foo;
+```
+
+```js
+// Bad: String defaults not sorted alphabetically
+const { b = "beta", a = "alpha", c } = foo;
+```
+
+```js
+// Bad: Properties reversed
+const { b, a } = foo;
+```
+
+### ✅ Correct
+
+```js
+// Good: Alphabetically sorted without defaults
+const { a, b, c, d } = foo;
+```
+
+```js
+// Good: Defaults first, sorted by type (string, number, boolean), then non-defaults
+const { d = "string", e = 0, f = true, a, b, c } = foo;
+```
+
+```js
+// Good: String defaults first (sorted alphabetically), then non-defaults
+const { a = "alpha", b = "beta", c, d } = foo;
+```
+
+```js
+// Good: Number defaults first (sorted alphabetically), then non-defaults
+const { a = 1, b = 2, c, d } = foo;
+```
+
+```js
+// Good: Boolean defaults first (sorted alphabetically), then non-defaults
+const { a = true, b = false, c, d } = foo;
+```
+
+```js
+// Good: Object defaults first (sorted alphabetically), then non-defaults
+const { a = {}, b = [], c, d } = foo;
+```
+
+```js
+// Good: Mixed default types sorted by type order, then non-defaults
+const { name = "default", age = 0, active = true, data = {}, x, y, z } = foo;
+```
+
+```js
+// Good: All defaults sorted by type and alphabetically
+const { a = "test", b = "value", c = 1, d = 2 } = foo;
+```
+
+```js
+// Good: With rest element at end
+const { a, b, ...rest } = foo;
+```
+
+## When Not To Use It
+
+If you prefer a different sorting strategy for destructured properties or don't want to enforce any particular order, you can disable this rule.
+
+## Further Reading
+
+- [Destructuring Assignment (MDN)](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Operators/Destructuring_assignment)
+- [Default Parameters (MDN)](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Functions/Default_parameters)

package/docs/rules/JSX_NO_NON_COMPONENT_FUNCTION.md

@@ -0,0 +1,114 @@
+# jsx-no-non-component-function
+
+Disallow non-component functions defined at top level in .tsx and .jsx files.
+
+## Rule Details
+
+This rule prevents non-component functions from being defined at the top level in `.tsx` and `.jsx` files. These functions should either be:
+
+1. Extracted to separate files and imported
+2. Defined inside the component function if they are component-specific
+
+### Why?
+
+1. **Better Organization**: Top-level functions in component files can accumulate and make files messy and hard to maintain
+2. **Proper Separation of Concerns**: Utility/helper functions belong in separate files, not in component files
+3. **Improved Reusability**: Extracting functions to separate files makes them easier to reuse across components
+4. **Cleaner Component Files**: Component files should focus on component logic only
+
+## Examples
+
+### ❌ Incorrect
+
+```tsx
+// Bad: Non-component function defined at top level in .tsx file
+const helper = (name: string) => {
+  const words = name.trim().split(/\s+/);
+  if (words.length === 1) {
+    return words[0].charAt(0).toUpperCase();
+  }
+  return words
+    .slice(0, 2)
+    .map((word) => word.charAt(0).toUpperCase())
+    .join("");
+};
+
+const Component = () => {
+  return <div>{helper("test")}</div>;
+};
+```
+
+```tsx
+// Bad: Function declaration at top level
+function formatName(name: string) {
+  return name.toUpperCase();
+}
+
+const Component = () => {
+  return <div>{formatName("test")}</div>;
+};
+```
+
+```tsx
+// Bad: Non-component function before exported component
+const calculateTotal = (items: number[]) => {
+  return items.reduce((sum, item) => sum + item, 0);
+};
+
+export const OrderSummary = () => {
+  return <div>Total</div>;
+};
+```
+
+### ✅ Correct
+
+```tsx
+// Good: Function imported from separate file
+import { helper } from "./helper";
+
+const Component = () => {
+  return <div>{helper("test")}</div>;
+};
+```
+
+```tsx
+// Good: Function defined inside component
+const Component = () => {
+  const helper = (name: string) => {
+    return name.toUpperCase();
+  };
+
+  return <div>{helper("test")}</div>;
+};
+```
+
+```tsx
+// Good: Component only
+const Component = () => {
+  return <div>Hello</div>;
+};
+```
+
+```tsx
+// Good: Functions in .ts or .js files are allowed
+// utils.ts
+export const helper = (name: string) => {
+  return name.toUpperCase();
+};
+```
+
+```tsx
+// Good: Exported component functions are allowed
+export const Component = () => {
+  return <div>Hello</div>;
+};
+```
+
+## When Not To Use It
+
+If you prefer to keep utility/helper functions in the same file as your components, you can disable this rule. However, this may lead to less organized code and reduced reusability.
+
+## Further Reading
+
+- [React Component File Structure Best Practices](https://react.dev/learn/thinking-in-react)
+- [Separation of Concerns](https://en.wikipedia.org/wiki/Separation_of_concerns)

package/docs/rules/JSX_NO_VARIABLE_IN_CALLBACK.md

@@ -0,0 +1,144 @@
+# jsx-no-variable-in-callback
+
+Disallow variable declarations inside callback functions within JSX.
+
+## Rule Details
+
+This rule prevents variable declarations inside callback functions that are directly used within JSX expressions. This enforces cleaner, more maintainable code by extracting complex logic to separate functions.
+
+### Why?
+
+1. **Readability**: Keeps JSX clean and focused on rendering, not logic
+2. **Maintainability**: Extracted functions are easier to test and modify
+3. **Separation of Concerns**: Logic belongs in functions, not inline in JSX
+4. **Consistency**: Enforces a uniform pattern across the codebase
+
+## Examples
+
+### ❌ Incorrect
+
+```tsx
+// Bad: Variable declared inside map callback in JSX
+const UserList = ({ users }) => {
+  return (
+    <div>
+      {users.map((user) => {
+        const displayName = user.firstName + " " + user.lastName;
+        return <div key={user.id}>{displayName}</div>;
+      })}
+    </div>
+  );
+};
+```
+
+```tsx
+// Bad: Variable in filter callback
+const ProductList = ({ products }) => {
+  return (
+    <ul>
+      {products.filter((product) => {
+        const isAvailable = product.stock > 0 && product.active;
+        return isAvailable;
+      })}
+    </ul>
+  );
+};
+```
+
+```tsx
+// Bad: Multiple variables in callback
+const OrderSummary = ({ orders }) => {
+  return (
+    <div>
+      {orders.map((order) => {
+        const total = order.price * order.quantity;
+        const discount = total * 0.1;
+        const final = total - discount;
+        return <div key={order.id}>{final}</div>;
+      })}
+    </div>
+  );
+};
+```
+
+### ✅ Correct
+
+```tsx
+// Good: Extract logic to a separate function
+const UserList = ({ users }) => {
+  const renderUsers = () =>
+    users.map((user) => {
+      const displayName = user.firstName + " " + user.lastName;
+      return <div key={user.id}>{displayName}</div>;
+    });
+
+  return <div>{renderUsers()}</div>;
+};
+```
+
+```tsx
+// Good: Use helper function outside JSX
+const ProductList = ({ products }) => {
+  const isProductAvailable = (product) => {
+    const isAvailable = product.stock > 0 && product.active;
+    return isAvailable;
+  };
+
+  return <ul>{products.filter(isProductAvailable)}</ul>;
+};
+```
+
+```tsx
+// Good: No variable declaration in callback
+const UserList = ({ users }) => {
+  return (
+    <div>
+      {users.map((user) => (
+        <div key={user.id}>
+          {user.firstName} {user.lastName}
+        </div>
+      ))}
+    </div>
+  );
+};
+```
+
+```tsx
+// Good: Variable declared outside JSX
+const OrderSummary = ({ orders }) => {
+  const discount = 0.1;
+
+  return (
+    <div>
+      {orders.map((order) => {
+        const total = order.price * order.quantity;
+        return <div key={order.id}>{total - total * discount}</div>;
+      })}
+    </div>
+  );
+};
+```
+
+```tsx
+// Good: Extract rendering to a function
+const OrderSummary = ({ orders }) => {
+  const calculateFinalPrice = (order) => {
+    const total = order.price * order.quantity;
+    const discount = total * 0.1;
+    return total - discount;
+  };
+
+  const renderOrders = () => orders.map((order) => <div key={order.id}>{calculateFinalPrice(order)}</div>);
+
+  return <div>{renderOrders()}</div>;
+};
+```
+
+## When Not To Use It
+
+If you prefer keeping all logic inline within JSX callbacks and don't mind the reduced readability, you can disable this rule. However, this is generally not recommended as it leads to harder-to-maintain code.
+
+## Further Reading
+
+- [React Component Best Practices](https://react.dev/learn/keeping-components-pure)
+- [Clean Code Principles](https://clean-code-developer.com/)

package/docs/rules/PREFER_JSX_TEMPLATE_LITERALS.md

@@ -0,0 +1,78 @@
+# prefer-jsx-template-literals
+
+Enforce using template literals instead of mixing text and JSX expressions.
+
+## 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)