ramda / eslint-plugin-ramda

:ram: ESLint rules for use with Ramda

Ramda

A practical functional library for JavaScript programmers.

Why Ramda?

There are already several excellent libraries with a functional flavor. Typically, they are meant to be general-purpose toolkits, suitable for working in multiple paradigms. Ramda has a more focused goal. We wanted a library designed specifically for a functional programming style, one that makes it easy to create functional pipelines, one that never mutates user data.

What's Different?

The primary distinguishing features of Ramda are:

• Ramda emphasizes a purer functional style. Immutability and side-effect free functions are at the heart of its design philosophy. This can help you get the job done with simple, elegant code.

• Ramda functions are automatically curried. This allows you to easily build up new functions from old ones simply by not supplying the final parameters.

• The parameters to Ramda functions are arranged to make it convenient for currying. The data to be operated on is generally supplied last.

The last two points together make it very easy to build functions as sequences of simpler functions, each of which transforms the data and passes it along to the next. Ramda is designed to support this style of coding.

Introductions

• Introducing Ramda by Buzz de Cafe
• Why Ramda? by Scott Sauyet
• Favoring Curry by Scott Sauyet
• Why Curry Helps by Hugh Jackson
• Hey Underscore, You're Doing It Wrong! by Brian Lonsdorf
• Thinking in Ramda by Randy Coulman

Philosophy

Using Ramda should feel much like just using JavaScript. It is practical, functional JavaScript. We're not introducing lambda expressions in strings, we're not borrowing consed lists, we're not porting over all of the Clojure functions.

Our basic data structures are plain JavaScript objects, and our usual collections are JavaScript arrays. We also keep other native features of JavaScript, such as functions as objects with properties.

Functional programming is in good part about immutable objects and side-effect free functions. While Ramda does not enforce this, it enables such style to be as frictionless as possible.

We aim for an implementation both clean and elegant, but the API is king. We sacrifice a great deal of implementation elegance for even a slightly cleaner API.

Last but not least, Ramda strives for performance. A reliable and quick implementation wins over any notions of functional purity.

Installation

To use with node:

$ npm install ramda

Then in the console:

const R = require('ramda');

To use directly in Deno:

import * as R from "https://deno.land/x/[email protected]/mod.ts";

or using Nest.land:

import * as R from "https://x.nest.land/[email protected]/mod.ts";

To use directly in the browser:

<script src="path/to/yourCopyOf/ramda.js"></script>

or the minified version:

<script src="path/to/yourCopyOf/ramda.min.js"></script>

or from a CDN, either cdnjs:

<script src="//cdnjs.cloudflare.com/ajax/libs/ramda/0.29.1/ramda.min.js"></script>

or one of the below links from jsDelivr:

<script src="//cdn.jsdelivr.net/npm/[email protected]/dist/ramda.min.js"></script>
<script src="//cdn.jsdelivr.net/npm/ramda@latest/dist/ramda.min.js"></script>

(note that using latest is taking a significant risk that ramda API changes could break your code.)

These script tags add the variable R on the browser's global scope.

Or you can inject ramda into virtually any unsuspecting website using the bookmarklet.

Note for versions > 0.25 Ramda versions > 0.25 don't have a default export. So instead of import R from 'ramda';, one has to use import * as R from 'ramda'; Or better yet, import only the required functions via import { functionName } from 'ramda';

Note for ES6 module and browsers In order to access to the ES6 module in browsers, one has to provide the content of the es directory (see below for the build instructions) and use import * as R from './node_modules/ramda/es/index.js';

Build

npm run build creates es, src directories and updates both dist/ramda.js and dist/ramda.min.js

Partial Builds

It is possible to build Ramda with a subset of the functionality to reduce its file size. Ramda's build system supports this with command line flags. For example if you're using R.compose, R.reduce, and R.filter you can create a partial build with:

npm run --silent partial-build compose reduce filter > dist/ramda.custom.js

This requires having Node/io.js installed and ramda's dependencies installed (just use npm install before running partial build).

Documentation

Please review the API documentation.

Also available is our Cookbook of functions built from Ramda that you may find useful.

The Name

Ok, so we like sheep. That's all. It's a short name, not already taken. It could as easily have been eweda, but then we would be forced to say eweda lamb!, and no one wants that. For non-English speakers, lambs are baby sheep, ewes are female sheep, and rams are male sheep. So perhaps ramda is a grown-up lambda... but probably not.

Running The Test Suite

Console:

To run the test suite from the console, you need to have mocha installed:

npm install -g mocha

Then from the root of the project, you can just call

mocha

Alternately, if you've installed the dependencies, via:

npm install

then you can run the tests (and get detailed output) by running:

npm test

Browser:

You can use testem to test across different browsers (or even headlessly), with livereloading of tests. Install testem (npm install -g testem) and run testem. Open the link provided in your browser and you will see the results in your terminal.

If you have PhantomJS installed, you can run testem -l phantomjs to run the tests completely headlessly.

Usage

For v0.25 and up, import the whole library or pick ES modules directly from the library:

import * as R from 'ramda'

const {identity} = R
R.map(identity, [1, 2, 3])

Destructuring imports from ramda does not necessarily prevent importing the entire library. You can manually cherry-pick methods like the following, which would only grab the parts necessary for identity to work:

import identity from 'ramda/src/identity'

identity()

Manually cherry picking methods is cumbersome, however. Most bundlers like Webpack and Rollup offer tree-shaking as a way to drop unused Ramda code and reduce bundle size, but their performance varies, discussed here. Here is a summary of the optimal setup based on what technology you are using:

1. Webpack + Babel - use babel-plugin-ramda to automatically cherry pick methods. Discussion here, example here
2. Webpack only - use UglifyJS plugin for treeshaking along with the ModuleConcatenationPlugin. Discussion here, with an example setup here
3. Rollup - does a fine job properly treeshaking, no special work needed; example here

Typings

• TypeScript
• Flow

Translations

• Chinese(中文)
• Ukrainian(Українська)
• Portuguese(BR)
• Russian(Русский)
• Spanish(ES)

Funding

If you wish to donate to Ramda please see our Open Collective page. Thank you!

Acknowledgements

Thanks to J. C. Phillipps for the Ramda logo. Ramda logo artwork © 2014 J. C. Phillipps. Licensed Creative Commons CC BY-NC-SA 3.0.

eslint-plugin-ramda's Issues

feat: suppress 'no-underscore-dangle' when using R.__

This is a Feature Request

Actual

R.__ causes no-underscore-dangle eslint error.

Desired

Ramda placeholder shouldn't cause this error.

Current Workaround

/* eslint no-underscore-dangle: ["error", { "allow": ["__"] }] */

const postProp = R.prop(R.__, { id: 2, title: 'Hello World', author: 'Giuseppe Mandato'});

[Chore] Update Node support

If you take a look at the Node release schedule, Node.js 4 is dropped, with 6, 8 and 10 being the current LTS versions, and 6 about to drop in April. I'd say it's okay to drop support for Nodes 4 and 5, based on that.

Add a rule to forbid import R from 'ramda'

Hi.

Because I use @types/ramda, estlint or TS seems not to complains about import R from 'ramda' (instead of import * as R from 'ramda')

In my case, it results in a R that is undefined and a broken js runtime.

I think it would be great to have a rule to prevent importing the default from ramda.

[prefer-ramda-boolean] detect always(true) / always(false)

It appears that always(true) and always(false) are not detected.

The following is missed:

const f1 = always(false);
const f2 = always(false);

Though perhaps this should be a separate rule.

Module prefixed names

I gave this a quick spin and ran into a difficulty. Namely, our code base generally imports Ramda as the R module and all references to Ramda functions are then prefixed with the module name. Not seeing any lint issues, I changed a use of R.pluck(...) to R.map(R.prop(...)) and I still didn't see any lint issues. Then I changed it to map(prop(...)) and got the lint issue I expected. Is there a way to configure this plugin with a module prefix?

Support custom definition of Ramda's module name

Currently, R is defined as the possible Ramda's module name, as stated in #17.
We need, at least, to have a configuration entry to customize the name of this variable.

Add URL to meta in rules

It is useful for code review as the rule is easily referenceable by URL.

Suggestion: AnyPass > Either, AllPass > Both When Only Two Predicates

How about a linting rule that looks for cases where anyPass or allPass have been used with only two predicates and enforces a replacement with either or both.

// Fail
anyPass([p1, p2])

// Replacement
either(p1, p2);

// Fail
allPass([p1, p2])

// Replacement
both(p1, p2)

[Feature Request] Suggestion of Ramda functions over built-ins

Hey, I'm new to Ramda and I think the feature in eslint-plugin-lodash that has it suggest the lodash functions over the built-in stuff would be pretty useful toward learning it. Especially since it's in their recommended setting and turning it on lights up your code to functions you might not be aware of. Just a thought though.

False positive ramda/cond-simplification

const entityTypeMapper = (...pairs) =>
  R.cond([
    ...pairs.map(([from, to]) => [R.propEq('type', from), R.assoc('type', to)]),
    [R.T, R.identity],
  ]);

ESLint config extended from plugin:ramda/recommended

tested with eslint 7 (and typescript-eslint 3)

Just wanted to mention that I tested with eslint 7 and typescript-eslint 3 and it seems to work.

[ramda/prefer-ramda-boolean] Wrong report in jest.mock implementation

The only way to access ramda in jest.mock is jest.mock('module', () => jest.requireActual('ramda').T). So it's not as convenient to use ramda in mocks. Maybe plugin can detect inline mocks and disable rule in them?

Feedback

You can just close this, but I figured I'd let y'all know.

I ran this against against a very large project that is using ramda extensively. I found 8 errors, all of which were valid and worth fixing.

I compared time that lint took
with eslint-plugin-ramda:

29.05s user 0.56s system 104% cpu 28.408 total

and without:

29.05s user 0.57s system 104% cpu 28.419 total

Support for Ramda imported with alias

Currently, we support linting code imported with:

import { ifElse, cond } from 'ramda'

and:

import R from 'ramda'

but things like:

import { ifElse as if_else }, Ramda from 'ramda'

won't be caught by the linter.

We need to think about a way to checking how Ramda was imported to figure out what to lint and avoid false positives or false negatives.