remeda

library2.33.7jsnpmunverified

Remeda is a modern, tree-shakable utility library for JavaScript and TypeScript, focusing on a functional programming paradigm with both "data-first" and "data-last" execution styles. It is currently at version 2.33.7 and receives frequent updates, often multiple bug-fix releases per month, with minor feature releases occurring periodically. Key differentiators include its robust, first-class TypeScript support, providing highly specific and accurate types for its extensive collection of utilities. Unlike older libraries, Remeda is designed from the ground up to support lazy evaluation through `pipe` and `piped`, offers full CJS and ESM compatibility, and ensures full code coverage with comprehensive runtime and type tests. It aims to provide a reliable and type-safe alternative to libraries like Lodash and Ramda, offering migration guides for users transitioning from those ecosystems.

serialization

npm install remeda

github ↗package ↗homepage ↗

INSTALL

IMPORT

SIG · REMEDA

remeda

serializationjavascriptv2.33.7

Install

—

Import

—

Disk

—

Pass rate

0/ 6

Env Coverage0 / 6

glibc

18–22

musl

18–22

Install & Compatibility

Where this runs

tested against v? · npm install

Install × environment matrix

Each cell = how many times install + import succeeded across repeated harness runs. Partial = flaky.
glibc = Debian/Ubuntu slim · musl = Alpine Linux

musl

node 18–226 runs

build_error

glibc

node 18–226 runs

build_error

Code

Verified usage

Verified import paths — ran on the pinned version, not inferred.

pipe

✓ import { pipe } from 'remeda';

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

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

map

✓ import { map } from 'remeda';

✗ import map from 'remeda/map';

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

unique

✓ import { unique } from 'remeda';

✗ import { uniq } from 'remeda';

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

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]

Debug

Known issues

breakingStarting 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) => ...)`.

affects: >=2.0.0

breakingRemeda 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`.

affects: >=2.0.0

breakingIn 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'.

affects: >=2.0.0

gotchaRemeda 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.

affects: >=2.0.0

gotchaMigrating 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.

affects: >=1.0.0

deprecatedThe `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.

affects: >=2.0.0

Errors

Common errors & fixes

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

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

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)

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.

Upgrade

Version history

2.33.7latest on npm

Audit

Dependencies

No dependency data recorded yet.

Agent activity

2 hits · last 30 days

node

Resources

githubhttps://github.com/remeda/remeda ↗

packagehttps://www.npmjs.com/package/remeda ↗

homepagehttps://remedajs.com ↗