Make ramda more modular

[luizbills]

my proposal

var R = require('ramda'); // import ALL ramda functions
var compose = require('ramda/compose'); // import JUST the compose function
...

[davidchambers]

require('ramda/src/compose') currently works, but it would be nice to use the cleaner path.

[luizbills]

That's the point. 👍

[CrossEye]

👍

We've discussed this before, but no one's gotten around to doing it. It should just be a matter of how the NPM package is built.

@luizbills: Do you feel up to taking a swing at it?

[luizbills]

This allows custom builds easy. Ramda is very big. Hardly ever someone will use the entire library.

[Hypercubed]

Any thoughts on converting to ES6 modules and using rollup? Tree-shaking Ramda with rollup would be amazing.

[CrossEye]

@Hypercubed: Could you describe the advantages? I haven't tried rollup yet.

Although it's not well-documented, it's fairly simple to build your own version of Ramda right now. This doesn't start with static analysis of a codebase, though, but with a list of public functions you want to include. The build does the recursive dependency management and builds as small a package as possible.

[Hypercubed]

Using ES6 modules would improve static analysis of the code base.... something that is difficult with CJS modules. On your end Rollup would do pretty much what you described... take an index file and build the smallest a package as possible (maybe replacing your build script).

I guess the advantage of using ES6 modules would be to allow users to do tree shaking on their end. They can import ramda methods individually, without the need to know the internal paths, then use rollup tree shaking to get a minimal build.

For example in my project I can do:

import {compose, isNil, equals} from 'ramda';

to get only the relevant portions of the ramda codebase.

Because Ramda is already pretty modular it's probably not to hard to convert to ES6 modules. The hard part would be converting the build process.

[CrossEye]

I don't think it would be hard to write a new build process to handle that. It would clearly work fine for browser usage. Even there, I have concerns about readability. I think of ramda.js as our flagship output. As much as possible, I would like that to remain as clean and readable, and as much like hand-crafted code as possible. But it's not at all clear that this would work for Node users. Right now Node users can use the same file that browser users do, and they can also import individual functions directly. (There is an unfortunate 'src' in the import path, but we can straighten that out..) If we switched to ES6 modules, would Node users would presumably have to run some build step before using the individual imports, and that seems to bad.

[Freyert]

Perhaps a feature branch could be started for the ES6 import. That way when it becomes the de facto it won't be but a hop skip and a jump for Ramda. Also, users who are just plain desperate for it right now would be able to clone from that branch.

I've proposed ES6 modules before, for the same reason @Hypercubed has. Perhaps we could tag team?

I think also with the rapidity that javascript is evolving it is probably going to be necessary to incorporate a transpilation step at some point. Hand crafted code is the best, but transpiled code would allow ramda to support a wider range.

Also, ES6 support could help Ramda dramatically improve other areas such as error handling. R.compose throws some fairly enigmatic errors if a function has issues, which makes it a hard sell to me coworkers. Function.name property would make it a more simple process by allowing us to throw the function name for any of the composed functions. (I could also just be doing this wrong.)

[scott-christopher]

I was messing around with ES modules in Ramda the other day, so I figured I'd push a branch up that people can experiment with: https://github.com/scott-christopher/ramda/tree/es-modules

Note: this is just a experiment, with no guarantees it will eventuate into anything

The UMD module generated by rollup is surprisingly not far off what the current Ramda build script produces: https://github.com/scott-christopher/ramda/blob/es-modules/dist/ramda-rollup.js

@CrossEye's point about continuing support for importing individual modules in commonjs environments still stands, meaning if we were to go down this path we would need to look into deploying separate packages to NPM to support both module types. That could be a good opportunity to solve for being able to import individual modules in commonjs environments while we're poking at it.

[davidchambers]

The UMD module generated by rollup is surprisingly not far off what the current Ramda build script produces

You're right! This is good to see. :)

[CrossEye]

@scott-christopher: This is great! I'd love to be using external tools for this rather than maintaining our own. All kudos to @davidchambers, whose script was much better than the one I was building, but I'd still rather work with a tool that's well-maintained, if it does as good a job as this.

[Hypercubed]

@scott-christopher It looks great. What else needs to be done? Might also consider adding Babel to the mix to allow proper ES6 code.

[borisirota]

Hi guys, this is really great!

I just want to add that its possible to add to @scott-christopher es-modules branch the following steps:

1. place index.js inside src dir.
2. run babel src --out-dir lib and use the babel-plugin-transform-es2015-modules-commonjs plugin (maybe rename the src directory to es and then make babel es --out-dir src for backwards compatibility for guys importing specific functions like ramda/src/compose).
3. change main field in package.json to "main": "src/index.js"
4. add to package.json "jsnext:main": "es/index.js"

Check out Redux as example. They develop with es6 features so they use additional babel plugins for the transpilation.

The benefits are (you mentioned almost all of them):

• Browser users - use rollup's output and rollup is the build tool.
• Node users - same way like today but behind the scenes it will be separate modules.
• Browserify\Webpack users - same way like today with the same ability to require separate functions.
• Rollup\Webpack 2 users - can use tree shaking with jsnext:main (webpack 2 will support it before release)
• @CrossEye - No build step from users and no need to deploy separate packages to NPM to support both module types.

I just started using ramda and its awesome !
Currently, the library size is something to think about before using it in web project. With this approach there is nothing to think about :)

BTW, babel-plugin-ramda (I made PR which adds babel 6 support) is a workaround for guys using babel in their build but it will be great to have it out of the box.