Remeda Utility Library

Common errors

• Argument of type '(...)' is not assignable to parameter of type '(...)'

  cause Remeda's types are highly specific, and this error indicates a mismatch between your input data's type or a callback's signature and what the Remeda function expects.
  fix Ensure your data types and function signatures align with Remeda's strict typings. You may need to refine your own type definitions, or use type assertions if you are certain of the type.

• TypeError: (0 , remeda_1.someFunction) is not a function

  cause This usually means you are attempting to use a CommonJS `require` call or an incorrect import path for a named ESM export in a context where the module resolution expects a different format or an incorrect name.
  fix Confirm you are using `import { someFunction } from 'remeda';` for named exports in an ESM context. Check your `tsconfig.json` and `package.json` for correct module resolution settings if using TypeScript or Node.js ESM.

• Property 'prop' does not exist on type '...' (when using `prop` in pipes with strict type configurations)

  cause When using `prop` (or similar accessors) in complex type scenarios, especially with unions or recursive objects, TypeScript might struggle to infer the exact type, leading to this error. There's an open issue related to `prop` and recursive objects.
  fix Consider narrowing the type before using `prop`, or explicitly type the object being accessed if the type inference is failing. For known issues, check Remeda's GitHub issues for workarounds or future fixes. You might need to use `as any` as a last resort, but this reduces type safety.

Warnings

• breaking Starting from Remeda v2, many functions that previously offered 'variants' (like `.indexed` or `.strict`) have merged these into the base implementation, changing default behaviors or callback signatures. Users migrating from v1 will need to adjust calls, especially for functions like `map` where the indexed variant is now always available.
  Fix: Consult the official Remeda v2 migration guide for specific function changes. For example, `map.indexed(DATA, ...)` becomes `map(DATA, (item, index) => ...)`.
• breaking Remeda v2 introduced several renames for functions to align with ECMAScript standards and improve clarity (e.g., `uniq` to `unique`, `fromPairs` to `fromEntries`, `createPipe` to `pipe`). Code using old names will break.
  Fix: Update function calls to use the new names as specified in the v2 migration guide. For instance, replace `uniq` with `unique`.
• breaking In v2, all single-parameter functions should now be called with no parameters to get their data-last (curried) implementation when used outside of a `pipe` context. Previously, some could be called 'headless' directly. This affects functions like `keys()` or `identity()` when curried.
  Fix: Ensure single-parameter functions are invoked with `()` if intended for data-last application (e.g., `pipe(data, keys())` instead of `pipe(data, keys)`). Type guards (e.g., `isString`) are exceptions and remain 'headless'.
• gotcha Remeda is TypeScript-first and provides very strict types. This is a feature but can lead to TypeScript errors if your data shapes or function arguments do not precisely match the expected types, especially when `exactOptionalPropertyTypes` is enabled (v2.33.1).
  Fix: Carefully review TypeScript errors. Adjust your data types or use type assertions (`as Type`) if you are confident in the data's structure. Consider enabling stricter TypeScript flags incrementally.
• gotcha Migrating from Lodash or Ramda requires understanding Remeda's distinct "data-first" and "data-last" philosophy and specific function signatures. Direct drop-in replacements may not work as expected, and some Lodash/Ramda features (like Lodash's mutable `forEach` early exit) are intentionally not replicated.
  Fix: Consult the official migration guides for Lodash and Ramda on remedajs.com for detailed function-by-function comparison and migration steps. Expect to refactor code rather than simply renaming functions.
• deprecated The `mapToObj` function is explicitly marked as deprecated and will be removed in future versions. It's advised against its usage unless for specific performance constraints with huge inputs.
  Fix: Replace `mapToObj` with `pullObject` or a composition of `fromEntries(map(array, fn))` to achieve similar results, which are generally more performant and idiomatic.

Install

• npm install remeda npm
• yarn add remeda yarn
• pnpm add remeda pnpm

Imports

• pipe
  wrong:

  const pipe = require('remeda').pipe;

  correct:

  import { pipe } from 'remeda';

  Remeda primarily uses named ESM imports. CommonJS require is supported but less common for new projects.
• map
  wrong:

  import map from 'remeda/map';

  correct:

  import { map } from 'remeda';

  Individual functions are imported directly from the 'remeda' package, not from subpaths. Remeda v2 changed module output structure.
• unique
  wrong:

  import { uniq } from 'remeda';

  correct:

  import { unique } from 'remeda';

  Some functions were renamed in v2 for better alignment with ECMAScript standards and clearer terminology (e.g., `uniq` became `unique`).

Quickstart

Demonstrates `pipe` for chaining multiple functional operations (forEach, unique, take) on an array in a data-first manner.

import { pipe, forEach, unique, take } from 'remeda';

const numbers = [1, 2, 2, 3, 3, 4, 5, 6];

const processedNumbers = pipe(
  numbers,
  forEach((value) => console.log(`Processing: ${value}`)), // Side effect
  unique(), // Removes duplicates
  take(3) // Takes the first 3 elements after uniqueness
);

console.log('Result:', processedNumbers);
// Expected console output:
// Processing: 1
// Processing: 2
// Processing: 2
// Processing: 3
// Processing: 3
// Processing: 4
// Processing: 5
// Processing: 6
// Result: [1, 2, 3]