Monorepos will ruin your life – but they're worth it | Hacker News Reader

Monorepos will ruin your life – but they're worth it

thenable.io

Try nx instead of lerna/yarn workspaces.

Nx will figure out the affected dependency graph for packages in your mono repo so you are able to only build/test/deploy the changes.

I just found NX halfway through building a new monorepo setup. I hope it's as good as it looks because I'm throwing out about a couple days of work to switch.

I use it, it's pretty good if you expect your project to grow pretty large. I wouldn't recommend it for something basic.

It can get hard to get some things working well. Eg expo, which has a 3rd party package, but it's usually pretty far behind on the version of nx it supports.

Personally, I've just started using blitz js for smaller things, no need to split things into packages.

It's good if you need to share components across multiple application. Has solid tooling and plug ins for all the relevant IDEs.

I know Productboard devs are using it with quite significant team (250 devs) so you can check their opinions

With nx, If you have a package that is imported into another can you have nodemon rebuild just the imported package? I have a heavy handed fix for yarn workspaces but it is hacky. I'd prefer a better solution if nx can do that.

No, thanks.

Monorepos might be good for Google or Facebook where you have company-size teams to maintain all the tooling around them and there is no risk of "the guy that did all the tooling left and now we don't know how this works anymore".

You're not facebook, you're not google.

Keep services on their own repositories, with their own pipelines, don't write internal libraries that reinvent the wheel, and if you do, just create them in their own repo and publish them as packages.

Monorepos and all the associated bullshit is for teams which want to do technology for the sake of technology and for their resume. 90% of companies don't need monorepos, don't waste company's time and money because something is just fun to you.

"If not managed correctly, monorepos can cause the build process to take just short of an eternity."

DAG Pipelines to the rescue! Even our horrific 40+ services with 5+ React apps monorepo only takes 10 minutes to build because we build everything in parallel!

> only takes 10 minutes

Is this a joke? That’s so long! I feel like 1 minute is too long since I lose my train of thought and get distracted

I'd love to see a certain pipeline I use to get under 20 minutes!

You ever work on a large C++ project and have to do a clean build? Expect up to an hour or more.

> 40+ services

Those are rookie numbers! We have literally 1000s of services and apps in one single monorepo. A full build in parallel takes upwards of 12 hours.

We have a long series [0] of article covering monorepos in node.js. It covers Lerna, versioning and publishing, enforcing Conventional Commit, and many other topics.

[0] https://www.adaltas.com/en/2021/01/05/js-monorepos-project-i...

Monorepos can be really powerful, but in choosing one (or frankly polyrepo) you need to admit your application is no longer simple. Now you have dependencies and multiple artifacts to deal with. I’ve found yarn berry (the typescript rewrite that is v2 and v3) really great for js centric monorepos. With pnp the node_modules problem goes away. And the plug-in architecture of yarn berry is really powerful. This is important because monorepos always need tooling specific to the problem to work well. Bazel, Buck and Pants are great in the Java/C world - but way to heavy for JS. I’ve shared this plugin before, but in case you missed it - I wrote yarn.build [0] as a lightweight replacement for Bazel et al for yarn. In yarn 3, this installs and vendors it into your repo:

    yarn plugin import https://yarn.build/latest

It’s really powerful when you use many local workspaces (packages), that have dependencies on each other. Provided they’re not circular. Theres a build command that runs in the right topological order calling build in your package.json. And caching the status of builds, so it only rebuilds with changes. After that I added a yarn test command, to do the same thing but run test. This has been really powerful for me. As it’s meant I can treat each workspace as if it was coming from NPM. As such, boundaries are hard, and defined. I often need to ship a nodejs lambda, so I added a bundle command. That works similar to how Bazel does a build. It copies your repo to a temporary directory. Then removes everything you don’t need (local workspaces that aren’t dependencies of the workspace to bundle). And drops an entrypoint.js in the root dir, that reexports your main script (as defined in package.json). Finally it zips it up, ready for lambda or any other nodejs environment. And finally, because yarn.build just calls the build script, it can build anything. So I’ve used I with go quite a bit. You just call go build in the package.json build script (add a test script and test it along with the other workspaces). But some go devs aren’t big fans of a package.json hanging around. So I wrote this other neat (and kinda wild) plug-in [1], that allows package.json to be written as package.yaml (with comments!). Like actual yaml.

    yarn plugin import https://yarn.build/yaml

The yaml plug-in sits in between the file system. It works much better than I expected, though I mostly use it on non-node stuff. As node expects package.json on disk for some stuff. Thankfully the plug-in is opt in per workspace, so it happily falls back to json if that’s there. And only uses yaml if there’s a package.yaml and no package.json.

[0] https://yarn.build

[1] https://github.com/ojkelly/yarn.build#plugin-package-yaml

Going to check these out! Thanks!

Points for an awesome title.

Reply on news.ycombinator.com