eslint-plugin-remeda 1.4.0 → 1.6.0

package/docs/rules/collection-method-value.md

@@ -1,4 +1,8 @@
-# Collection Method Value
+# remeda/collection-method-value
+
+💼 This rule is enabled in the ✅ `recommended` config.
+
+<!-- end auto-generated rule header -->
 
 When using a Remeda collection method, the expression should be used (e.g. assigning to a variable or check in a condition), unless it's a method meant for side effects (e.g. `forEach` or `forOwn`) which should NOT be used.
 

package/docs/rules/collection-return.md

@@ -1,4 +1,8 @@
-# Collection Return Statement
+# remeda/collection-return
+
+💼 This rule is enabled in the ✅ `recommended` config.
+
+<!-- end auto-generated rule header -->
 
 When using a Remeda collection method that isn't forEach, the iteratee should return a value, otherwise it could result in either unclear code or unexpected results.
 

package/docs/rules/prefer-constant.md

@@ -1,4 +1,8 @@
-# Prefer constant
+# remeda/prefer-constant
+
+💼 This rule is enabled in the ✅ `recommended` config.
+
+<!-- end auto-generated rule header -->
 
 When you want a function that always returns the same value, it can be more concise to use `R.constant`.
 
@@ -9,6 +13,10 @@ This rule takes two arguments:
 - whether or not to check arrow functions
 - whether or not to check function declarations (named functions)
 
+## Options
+
+## Examples
+
 The following patterns are considered warnings:
 
 ```js

package/docs/rules/prefer-do-nothing.md

@@ -1,4 +1,8 @@
-# Prefer noop
+# remeda/prefer-do-nothing
+
+💼 This rule is enabled in the ✅ `recommended` config.
+
+<!-- end auto-generated rule header -->
 
 When defining an empty function (e.g. for callbacks) it can be more readable to use `R.doNothing()` or `R.constant(undefined)` instead. Use `R.doNothing()` if you need to return void, otherwise use `R.constant(undefined)`.
 

package/docs/rules/prefer-filter.md

@@ -1,4 +1,8 @@
-# Prefer filter
+# remeda/prefer-filter
+
+💼 This rule is enabled in the ✅ `recommended` config.
+
+<!-- end auto-generated rule header -->
 
 When using R.forEach with a single `if` statement, you should probably use `R.filter` or `R.some` instead.
 
@@ -6,6 +10,10 @@ When using R.forEach with a single `if` statement, you should probably use `R.fi
 
 This rule takes one argument, maximum path length (default is 3).
 
+## Options
+
+## Examples
+
 The following patterns are considered warnings:
 
 ```js

package/docs/rules/prefer-find.md

@@ -1,4 +1,8 @@
-# Prefer find
+# remeda/prefer-find
+
+💼 This rule is enabled in the ✅ `recommended` config.
+
+<!-- end auto-generated rule header -->
 
 When using R.filter and accessing the first or last result, you should probably use `R.find` or `R.findLast`, respectively.
 

package/docs/rules/prefer-flat-map.md

@@ -1,4 +1,8 @@
-# Prefer [`R.flatMap`] over consecutive [`R.map`] and [`R.flat`]
+# remeda/prefer-flat-map
+
+💼 This rule is enabled in the ✅ `recommended` config.
+
+<!-- end auto-generated rule header -->
 
 When using [`R.map`] and [`R.flat`], it can be more concise to use [`R.flatMap`] instead.
 

package/docs/rules/prefer-has-atleast.md

@@ -0,0 +1,89 @@
+# remeda/prefer-has-atleast
+
+💼 This rule is enabled in the ✅ `recommended` config.
+
+<!-- end auto-generated rule header -->
+
+When checking if an array has at least a certain number of elements, it is more expressive to use `R.hasAtLeast` instead of comparing the array's length with a number.
+
+Additionally, when checking if an array is not empty, it's better to use `R.hasAtLeast(data, 1)` instead of negated `R.isEmpty(data)` patterns (`!R.isEmpty(data)`) because the TypeScript type narrowing works better with `hasAtLeast`.
+
+## Rule Details
+
+The following patterns are considered warnings:
+
+```js
+// Array length comparisons
+if (array.length >= 3) {
+  // ...
+}
+
+if (array.length > 2) {
+  // ...
+}
+
+if (3 <= array.length) {
+  // ...
+}
+
+if (2 < array.length) {
+  // ...
+}
+
+// Negated isEmpty patterns (problematic for TypeScript type narrowing)
+if (!R.isEmpty(array)) {
+  // TypeScript won't narrow the array type here
+}
+
+if (R.isEmpty(array) === false) {
+  // Same issue with type narrowing
+}
+
+if (R.isEmpty(array) !== true) {
+  // Same issue with type narrowing
+}
+```
+
+The following patterns are not considered warnings:
+
+```js
+// Using hasAtLeast
+if (R.hasAtLeast(array, 3)) {
+  // ...
+}
+
+// For non-empty checks, use hasAtLeast with 1
+if (R.hasAtLeast(array, 1)) {
+  // TypeScript correctly narrows the type here
+}
+
+// Other length comparisons
+if (array.length === 3) {
+  // ...
+}
+
+if (array.length < 3) {
+  // ...
+}
+
+if (array.length <= 3) {
+  // ...
+}
+
+// Regular isEmpty checks are fine
+if (R.isEmpty(array)) {
+  // ...
+}
+```
+
+## Type Safety Improvement
+
+From Remeda documentation:
+
+> "This guard [isEmpty] doesn't work negated because of typescript limitations! If you need to check that an array is not empty, use R.hasAtLeast(data, 1) and not !R.isEmpty(data). For strings and objects there's no way in typescript to narrow the result to a non-empty type."
+
+Using `R.hasAtLeast(array, 1)` instead of `!R.isEmpty(array)` improves type safety because TypeScript can properly narrow the array type to a non-empty array, which helps prevent "possibly undefined" errors when accessing array elements.
+
+## When Not To Use It
+
+If you do not want to enforce using `R.hasAtLeast` or prefer the explicit array length comparison, you should not use this rule. However, consider enabling it at least for the negated `isEmpty` patterns to improve type safety.

package/docs/rules/prefer-is-empty.md

@@ -1,4 +1,10 @@
-# Prefer R.isEmpty
+# remeda/prefer-is-empty
+
+💼 This rule is enabled in the ✅ `recommended` config.
+
+🔧 This rule is automatically fixable by the [`--fix` CLI option](https://eslint.org/docs/latest/user-guide/command-line-interface#--fix).
+
+<!-- end auto-generated rule header -->
 
 When checking if a collection is empty or no, it is more concise to use R.isEmpty instead.
 

package/docs/rules/{prefer-is-nil.md → prefer-is-nullish.md}

@@ -1,6 +1,6 @@
-# Prefer R.isNil
+# Prefer R.isNullish
 
-When checking that a value is undefined or null (but not false or ''), it is more concise to use R.isNil instead.
+When checking that a value is undefined or null (but not false or ''), it is more concise to use R.isNullish instead.
 
 ## Rule Details
 
@@ -17,11 +17,11 @@ var t = x === undefined || x === null;
 The following patterns are not considered warnings:
 
 ```js
-var t = R.isNil(x);
+var t = R.isNullish(x);
 
 var t = R.isUndefined(x) || R.isNull(y);
 ```
 
 ## When Not To Use It
 
-If you do not want to enforce using `R.isNil`, and prefer using specific checks instead.
+If you do not want to enforce using `R.isNullish`, and prefer using specific checks instead.

package/docs/rules/prefer-map.md

@@ -1,4 +1,8 @@
-# Prefer map
+# remeda/prefer-map
+
+💼 This rule is enabled in the ✅ `recommended` config.
+
+<!-- end auto-generated rule header -->
 
 When using `R.forEach` that pushes into an array, it could improve readability to use `R.map` instead.
 

package/docs/rules/prefer-nullish-coalescing.md

@@ -1,4 +1,10 @@
-# Prefer nullish coalescing over checking a ternary with !isNil.
+# remeda/prefer-nullish-coalescing
+
+💼 This rule is enabled in the ✅ `recommended` config.
+
+🔧 This rule is automatically fixable by the [`--fix` CLI option](https://eslint.org/docs/latest/user-guide/command-line-interface#--fix).
+
+<!-- end auto-generated rule header -->
 
 When checking if a variable is not nil as a test for a ternary equation, it's more coincise to just use the nullish coalescing operator.
 
@@ -9,13 +15,13 @@ This rule takes no arguments.
 The following patterns are considered warnings:
 
 ```js
-const myExpression = !isNil(myVar) ? myVar : myOtherVar;
+const myExpression = !isNullish(myVar) ? myVar : myOtherVar;
 ```
 
 The following patterns are not considered warnings:
 
 ```js
-const myExpression = !isNil(myVar) ? mySecondVar : myThirdVar;
+const myExpression = !isNullish(myVar) ? mySecondVar : myThirdVar;
 
 const myExpression = myVar ?? myOtherVar;
 ```

package/docs/rules/prefer-remeda-typecheck.md

@@ -1,4 +1,8 @@
-# Prefer Remeda typecheck
+# remeda/prefer-remeda-typecheck
+
+💼 This rule is enabled in the ✅ `recommended` config.
+
+<!-- end auto-generated rule header -->
 
 Getting the specific type of a variable or expression can be done with `typeof` or `instanceof`. However, it's often more expressive to use the Remeda equivalent function
 

package/docs/rules/prefer-some.md

@@ -1,4 +1,8 @@
-# Prefer R.some
+# remeda/prefer-some
+
+💼 This rule is enabled in the ✅ `recommended` config.
+
+<!-- end auto-generated rule header -->
 
 When comparing the index of an item with an `findIndex` method, it can be more expressive to use `R.some`, when only the sole existence of a matching item is taken into account.
 

package/docs/rules/prefer-times.md

@@ -1,4 +1,8 @@
-# Prefer R.times
+# remeda/prefer-times
+
+💼 This rule is enabled in the ✅ `recommended` config.
+
+<!-- end auto-generated rule header -->
 
 When using `R.map` in which the iteratee does not have any arguments, it's better to use `R.times`.
 

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "eslint-plugin-remeda",
-  "version": "1.4.0",
+  "version": "1.6.0",
   "author": "Andrea Pontrandolfo <andrea.pontra@gmail.com>",
   "description": "ESLint plugin for Remeda library.",
   "type": "module",
@@ -16,6 +16,8 @@
     "attw": "attw --pack .",
     "qa": "pnpm typecheck && pnpm test && pnpm knip && pnpm publint && attw",
     "nuke": "rm -rf node_modules pnpm-lock.yaml",
+    "update:eslint-docs": "eslint-doc-generator",
+    "lint:eslint-docs": "pnpm update:eslint-docs -- --check",
     "semantic-release": "pnpm build && semantic-release"
   },
   "files": [
@@ -26,8 +28,14 @@
   "exports": {
     "./package.json": "./package.json",
     ".": {
-      "import": "./dist/index.js",
-      "default": "./dist/index.cjs"
+      "import": {
+        "types": "./dist/index.d.ts",
+        "import": "./dist/index.js"
+      },
+      "require": {
+        "types": "./dist/index.d.cts",
+        "require": "./dist/index.cjs"
+      }
     }
   },
   "repository": {
@@ -40,23 +48,26 @@
     "eslint": ">=9.0.0"
   },
   "devDependencies": {
-    "@arethetypeswrong/cli": "^0.15.4",
+    "@arethetypeswrong/cli": "^0.17.4",
+    "@sherifforg/cli": "^8.2.0",
     "@types/lodash-es": "^4.17.12",
-    "@types/node": "^20.14.9",
-    "@vitest/coverage-v8": "^2.0.3",
-    "@vitest/ui": "^2.0.3",
-    "eslint": "9.10.0",
-    "eslint-config-sheriff": "^21.2.0",
-    "eslint-define-config": "^2.1.0",
-    "eslint-plugin-eslint-plugin": "^6.2.0",
-    "eslint-vitest-rule-tester": "^0.3.3",
-    "knip": "^5.29.1",
+    "@types/node": "^22.14.0",
+    "@vitest/coverage-v8": "^3.1.1",
+    "@vitest/ui": "^3.1.1",
+    "eslint": "9.24.0",
+    "eslint-config-sheriff": "^27.0.0",
+    "eslint-doc-generator": "^2.1.2",
+    "eslint-plugin-eslint-plugin": "^6.4.0",
+    "eslint-vitest-rule-tester": "^2.2.0",
+    "lodash-es": "^4.17.21",
+    "knip": "^5.49.0",
     "prettier": "^3.3.2",
-    "publint": "^0.2.10",
+    "publint": "^0.3.10",
     "semantic-release": "^24.0.0",
-    "tsup": "^8.2.4",
+    "tsup": "^8.4.0",
     "typescript": "^5.5.2",
-    "vitest": "^2.0.3"
+    "@typescript-eslint/utils": "^8.29.0",
+    "vitest": "^3.1.1"
   },
   "engines": {
     "node": ">=20"
@@ -75,7 +86,5 @@
     "fp"
   ],
   "license": "MIT",
-  "dependencies": {
-    "lodash-es": "^4.17.21"
-  }
+  "sideEffects": false
 }