Mentioning ramda-* libraries in README.md

[guillaumearm]

Hi, I think mentioning some useful ramda libraries, like ramda-adjunct and ramda-debug could be a good idea.

We can discuss about a list here.

https://github.com/char0n/ramda-adjunct
https://github.com/sebinsua/ramda-debug

In the future, when ramda will be very popular, maybe we will need to create a awesome-ramda repository 😆

[buzzdecafe]

There is a "related libraries" section here:
https://github.com/ramda/ramda/wiki

but i have no objection to raising the profile further

[guillaumearm]

Oh 😶, I didn't see that, sorry.

To be honest, I falled in love of the ramda-adjunct library, and i decided to begin to contribute to it.

I think it's the missing piece of ramda : additional predicates, combinators, higher order functions, and so on.

In addition, it's a very serious library.

Finally, why not integrate this kind of libraries in the ramda project ? (multi packages repo)
it can only increase the quality of this libraries to doing that, and we can start to build a consistent ramda ecosystem.

But there is a price : a lot of work 😂

some famous libraries doing that : react, babel, webpack, and so on.
There is a library to manage multi packages repo.
Take a look to https://lernajs.io/

[CrossEye]

It's not quite clear to me what you're suggesting.

I would have no problem hosting the ramda-adjunct project in the ramda organization, if the maintainers want to do so.

But I am not interested in folding the functions from ramda-adjunct into ramda itself. The library if, if anything, too large already.

[guillaumearm]

The idea is to put the source code of ramda-adjunct into ramda repository,
assuming that packages/ramda-adjunct/ folder have it's own package.json file.

Perhaps you would put ramda-fantasy too in this folder.

Obviously, packages/ folder is not uploaded when you publish ramda

feel free to read https://github.com/babel/babel/blob/master/doc/design/monorepo.md

I know it's a lot of efforts, but i'm ready to contribute if you're ok (and for sure, if @char0n agree too)

[CrossEye]

Although I know some of the basics of monorepos, and have even been involved in a few discussions at a job about whether we wanted to move to that model, I don't have any real sense what that might mean for a project like Ramda.

Ramda is mostly used through NPM. And we can tell people that to use Ramda, you just need to do

npm install ramda

import * as R from ramda

Would that still be true if we went down the monorepo path? If not, how different would it be?

All the projects included in Ramda are collectively plenty small enough to fit inside one reasonable sized repository. But I would be interested in it only if we can see that the transition is easy (for our users, mostly, but also for us) or that the benefits hugely outweigh the drawbacks. Can you convince me?

[guillaumearm]

Don't worry about users, there are no breaking changes.

npm install ramda and the import * as R from 'ramda' will still true even if we choose to work in the same repo.

The main goal

The goal is to share the same issues, same commits, same community, same problems, same ideas, same tools.

For example, if someone propose to add a function in ramda, we will dicuss about where this function will go, and so on...

A lot of changes

But as I said, it's a lot of work :

• git workflow reconciliation
• use of lerna
• team management
• project re-organization

Advantages

Advantages for ramda are :

• encourage collaboration
• ensure consistence between ramda modules
• grow ramda community through sharing
• learn new things about project management

Disadvantages

For me, disadvantages are same as said on : https://github.com/babel/babel/blob/master/doc/design/monorepo.md

• Codebase looks more intimidating.
• Repo is bigger in size.
• Can't npm install modules directly from GitHub
• ???

There are unknown factors, I will continue to dig into "monorepos" stuff to bring more feedback about it.

---

I know, it sounds like fashion stuff, because lots of famous repository use monorepos.
We can easily think that is overkilled and inconvenient, but with a long term thinking, we can imagine awesome advantages.

if this proposal annoy you, I would understand, it's a big deal.

---

On the other hand, it's not the initial subject of this issue, maybe we can start another issue for this proposal and continue to discuss about it.

For now, adding ramda-adjunct to ramda organization can be a good start.

[guillaumearm]

I started another issue (#2443) about this, sorry for off topic.

[CrossEye]

Ok. This is definitely worth discussing, but I'm closing this issue in favor of that one.