Monorepo Migration

[erquhart]

Closes #1410.

High points

• 24 packages total
• Webpack is building everything, both development and production (not the norm)
• Babel 7
• Webpack 4
• CSS is out, Emotion is in
• Main package went from 1.8MB to 2.0MB (this is actually not bad for stock webpack on a monorepo)

Answering your questions before you ask them

Why Webpack for everything?

Most monorepos are libraries, and most libraries aren't built with Webpack. Usually Babel or Rollup are used for production, as they typically excel at producing leaner bundles.

The short answer is that Netlify CMS is an application, not a library, so it's dependencies aren't quite as focused as a typical library. Our packages import all kinds of stuff, and we really need the build tooling to Just Work™. After many, many, many hours of toil, I can confirm that no other tooling was able to stomach our dependency graph nearly as well as Webpack + Babel. Rollup came close at some points, but there were a lot of gotchas for our use case.

To be clear: we'd ideally use Rollup for most of our packages. Maybe in the future.

Why Emotion?
Because CSS is for babies.

Seriously, though, CSS hit the scale limit once we split into a bunch of packages that needed to share styles, with surely more to come. Emotion gives us the beauty of the Styled Components approach with the "just make a classname" flexibility of CSS modules, for those times when you need it. And we did have those times.

Tour of the new digs

We really need to document a whole lot of stuff now. Here's the lightning tour:

• Everything is in /packages.
• Some libs were created from code that used to be core, namely around auth, helper functions, and error handling.
• Some UI was centralized into a new lib, too, a trend I expect to continue.
• All extensions now live in their own package, including widgets, backends, and editor components.
• We finally have a core package, though it isn't nearly as thin as I had hoped.
• /packages/netlify-cms = the good ol' package you know and love. A tiny wrapper that preloads all of the official extensions.

NPM is your friend.

If you want to use the core with a select few extensions, you'll need to use NPM. The netlify-cms package is a good example of how to do this, and it's fairly straightforward. The reason you need to use npm and bundle it up is "because builds". We need to get a shared dependency scheme going so that every widget doesn't have to cart around the same 800kb of dupe code. If you tried to throw together the core and some widgets via script tags in the browser today, it won't work. This is still a massive step forward, and we haven't lost any of the flexibility Netlify CMS already had, but it's sure to trip some folks up. Please be patient as we tumble down the rabbit hole of hip new tools wise architectural decisions.

What now?

More modularity. The more consumable pieces Netlify CMS exists in, the more clearly defined extension points become, and the more obvious examples everyone has on how to do cool things within. You can still use Netlify CMS like you always have, but it's simpler than ever to make your own version of an "official" widget and whip up a CMS instance with just the extensions you choose. We're stoked at the possibilities. Let us know what you think!

[verythorough]

Deploy preview for netlify-cms-www ready!

Built with commit 77021ed

https://deploy-preview-1515--netlify-cms-www.netlify.com