Ramda Adjunct: the utility shelf next to Ramda

The name explains the scope

Ramda Adjunct is described as the most popular and most comprehensive set of functional utilities for use with Ramda, providing a variety of useful, well tested functions with excellent documentation.

The name is defined in the readme, and the definition is a useful constraint rather than a joke. An adjunct is a thing added to something else as a supplementary rather than an essential part, and that something else is Ramda.

So the collection is deliberately the gap next to Ramda rather than a fork of it. It does not try to be a general purpose utility library, it does not reimplement Ramda, and it does not compete with Lodash. It holds the functions that you would write by composing Ramda's functions, the aggregate helpers that Ramda does not ship, and nothing else.

The full catalogue is in the documentation, and the readme links to the documentation for the latest release, with pages for the previous release and for all versions, and a VERSIONS.md file in the repository for the long tail.

The project is BSD 3-Clause licensed, written in JavaScript, the home page is the generated documentation site, and the release history is the 5.x and 6.x lines with 5.1.0 in August 2024, 6.0.0 in December 2025 and 6.1.0 in June 2026, with the last push to the repository on 2026-10-22 and the manifest at 6.2.0.

The motivation is a wheel everybody reinvents

The motivation section of the readme is two sentences, and they are the whole argument.

It is very common for people to create their own utils and recipes by composing Ramda's functions and creating more complex aggregate functions. Ramda Adjunct eliminates this repetitive wheel of reinvention and centralises the commonly used and useful utils.

That is a modest claim, and it is the right one. The thing being solved is not a missing feature but a repeated chore, and the people who feel it are the teams where three projects have each written their own isNil, their own toPairs, their own difference between two dates, each with a slightly different bug.

The three benefits the readme lists follow from that. The first is centralisation, because all the Ramda recipes and aggregate utilities that are not present in Ramda live in one place, and there is no more need for everybody to create their own utils in their own libraries or in each codebase.

The second is tests. The readme says Ramda Adjunct maintains maximal code coverage and mimics Ramda's test patterns, and the promise to the reader is that you can trust the functions. The codecov badge and the coverage configuration in the repository are what back that up.

The third is documentation, and it is the one that is unusual. The readme says you cannot call a library great if it lacks great documentation, and that Ramda Adjunct generates its documentation directly from its codebase and uses patterns found in both Ramda and Lodash to document its API. So the doc comments are not a separate chore, they are in the code, and the published site is a build artefact.

Three ways to load it, and one of them is a global

The usage section covers the three module systems the library supports, and the third one is the interesting case.

For a modern build, the ES module form, either a namespace import of the whole library or a named import of a single function. For a server, the CommonJS require, again whole or named.

For a plain HTML page, the readme shows two script tags, one for Ramda itself and one for the browser build of Adjunct, or a single standalone tag. Including Ramda Adjunct in an HTML document exposes a global variable named RA on the window object, and the readme's example calls it directly.

The global is a deliberate choice for the people who are not using a bundler, and it comes with the usual consequences, which the library does not pretend otherwise. The standalone build is what a page can load on its own, and it is the file the manifest points at for the unpkg and jsDelivr fields.

import * as RA from 'ramda-adjunct'

RA.isArray([]);

and the named form is the same call without the namespace. The whole point of the named form is tree-shaking, which is what the sideEffects field in the manifest is for, since a bundler can only drop an unused export if the package declares that dropping it has no side effects.

A Node floor from 2016 and a build that still targets it

The requirements section is short and its numbers are old, which is the interesting part.

The requirements are Ramda 0.32.0 or newer and Node 0.10.48 or newer. The library is automatically tested against all the LTS and current Node.js versions.

The legacy builds section explains the other half. The npm distributions are built with Webpack and Babel to support legacy versions of Node starting from 0.10.48. Although all the tests run against all the LTS and current Node versions, the project relies on Webpack and Babel to transpile Ramda Adjunct into a legacy ES5 bundle, and it notes that the ES5 distributions may run on Node versions older than 0.10.48 as long as those versions support ES5.

That is an unusual amount of care for a package whose runtime dependency is a modern library, and the reason is visible in the manifest, which declares the engine as Node 0.10.3 or newer, which is older still than the stated requirement. The engines field is what npm warns about during installation, so it has to be no higher than what the shipped code actually supports, and the published code is the transpiled one.

The practical consequence is that the library is usable in a build pipeline you would not want to modernise, which is the point of a utility shelf. The cost is a build step in the repository that exists only to keep an old runtime alive.

The manifest is a compatibility contract

The package manifest is the clearest statement of what the library promises, and several of its fields are there to serve a specific consumer.

The module fields are the usual pair, main pointing at the CommonJS build in lib and module pointing at the ES module build in es, with the same path repeated for the jsnext:main field for older bundlers. The exports map then gates both entry points, and the types field points at a hand-written declaration file in the types directory, which is how the library ships type information without depending on the TypeScript compiler being present in the consumer's build.

The unpkg and jsdelivr fields both point at the same file, the standalone minified browser bundle, which is what a page with a script tag loads and what the readme's single tag example uses.

Two more fields are worth naming. The type field is set to module, so the package is an ES module package even though it ships a CommonJS build, and the sideEffects field is false, which is the promise that importing the module has no side effects and that a bundler may drop unused exports. For a utility library with a large catalogue, that field is the difference between a bundle that carries a hundred unused functions and one that carries three.

The funding field points at Open Collective, and the readme carries the backer and sponsor badges, which is how a project without a company behind it pays for its time.

The repository shows a project with a process

The file listing is long for a utility library, and the length is the point.

There is a governance document, a release document, a security policy, a code of conduct, a contributing guide, a changelog and a VERSIONS.md that indexes the documentation of every past release. There is a commitlint configuration and a pre-commit setup with husky and a lint-staged configuration.

The test setup is also conventional and shows how the library is checked. There is a Mocha configuration, a c8 coverage configuration, a testem file for browser testing, and a Webpack configuration for the test build of the web bundle, separate from the configuration that builds the shipped one. A small example file at the root, tonicExample.js, is the kind of thing a maintainer writes to check the distribution in a plain script.

The documentation tooling is worth singling out, because it is what produces the site the readme links to. There is a jsdoc configuration file and a jsdoc.json, and the badge claims the documentation is at one hundred percent, which is a claim about the source comments rather than about the site.

The rest of the readme is a list of places the library has been written about, an article on why the library exists, a conference talk on functional programming with Ramda, and a set of links from other people's projects, which is the usual sign of a library that has become part of somebody else's tooling.

Editorial conclusion

Ramda Adjunct fits a team that has standardised on Ramda and keeps finding that the same handful of recipes, a type check, a debounce, a date helper, is being written in every codebase, because the library is exactly that catalogue and it is tested the way Ramda itself is tested. It is the wrong choice if you do not use Ramda, since the utilities assume a curried, immutable style, and it is the wrong choice if you are starting a new project, since the point of a utility library is to be a shared shelf rather than a dependency. Before you adopt it, check the version of Ramda you are on, because the requirement is a recent one, and read the legacy build section, because the package ships a transpiled ES5 bundle that will work in environments your build pipeline will not.

Frequently asked questions

Official sources

1. char0n/ramda-adjunct on GitHub
2. License: BSD-3-Clause
3. Project website
4. README
5. Releases