Monorepo/package set options

[andywhite37]

There has been some discussion about moving all the relude ecosystem libraries into a monorepo to solve some of the build and versioning woes with having separate repos. I think this might be a beneficial direction, but I wanted to list out some pros and cons, and also propose an alternative path to explore: trying to build out a package-set ecosystem within Reason.

Monorepo

The idea with a monorepo would be to move all the relude-* libraries into a single code repository, and set up some tooling support to centralize the versioning of dependencies, and have scripts to execute commands consistently on each of the packages.

• Pros
  • Centralized versioning
  • Centralized management of builds/scripts
  • Better confidence in ecosystem library compatibility
  • Centralized release/packaging
• Cons
  • Good for the libraries we own/maintain, but other libraries don't get the benefits and are left on their own to deal with versioning/scripts/etc.
  • Monorepos can become large, complicated, and hard to work with
  • Tooling support for monorepos has not been great - maybe it will improve with melange

Package sets

The idea of package sets can be seen in things like purescript package-sets, or Haskell stack. Rather than putting all the code into a single code repository, you create the notion of a set of packages that can be built together, and are proven to work nicely together via an automated build+test cycle. Having a set of packages that are known to work well together also reduces the burden of developers when they have to cobble together libraries that use various different versions of the same dependencies.

• Pros
  • All libraries get equal treatment, and are held to the same level of accountability in being a member of the package set
  • Builds can guarantee compatibility beyond just the packages of a monorepo
  • Package set can grow to include as many libraries as we want to support, even without the cooperation of the owners of those packages
  • Package set can become a community owned/maintained resource
• Cons
  • Tooling support for package-sets is basically non-existent for Reason - would need to build or try to leverage something like spago
    • I started to look into this at one point, and there is an old closed issue about this in the spago repo, but it didn't go anywhere at the time. I'm not sure using spago will be the easiest path, because it's currently very much about purescript, and adding in the reason tooling would probably make things more messy. It might be possible though.
  • Maintaining a package set is a non-trivial burden in terms of CI cost and actually fixing issues with dependencies.