Hacker News Reader

Comment by littlecranky67 | Hacker News Reader

We are using NX heavily (and are not affected) in my teams in a larger insurance company. We have >10 standalone line of business apps and 25+ individual libraries in the same monorepo, managed by NX. I've toyed with other monorepo tools for these kind of complex setup in my career (lerna, rushjs, yarn workspaces) but not only did none came close, lerna is basically handed over to NX, and rushjs is unmaintained.

If you have any proposal how to properly manage the complexity of a FE monorepo with dozens of daily developers involved and heavy CI/CD/Devops integration, please post alternatives - given that security incident many people are looking.

View on HN

Shameless self-plug and probably not what you're looking for, but anyway: I've created https://github.com/abuob/yanice for that sort of monorepo-size; too many applications/libraries to be able to always run full builds, but still not google-scale or similar.

It ultimately started as a small project because I got fed up with NX' antics a few years back (I think since then they improved quite a lot though), I don't need caching, I don't need their cloud, I don't need their highly opinionated approach on how to structure a monorepository; all I needed was decent change-detection to detect which project changed between the working-tree and a given commit. I've now since added support to enforce module-boundaries as it's definitely a must on a monorepo.

In case anyone wants to try it out - would certainly appreciate feedback!

https://moonrepo.dev/ worked great for our team's setup. It also support bazel remote cache, agnostic to the vendor.

npm workspaces and npm scripts will get you further than you might think. Plenty of people got along fine with Lerna, which didn't do much more than that, for years.

I will say, I was always turned off by NX's core proposition when it launched, and more turned off by whatever they're selling as a CI/CD solution these days, but if it works for you, it works for you.

I'd recommend pnpm over npm for monorepos. Forcing you to be explicit about each package's dependencies is good.

I found npm's workspace features lacking in comparison and sparsely documented. It was also hard to find advice on the internet. I got the sense nobody was using npm workspaces for anything other than beginner articles.

In the context of what we're talking about here, using the default package manger to install a different package manger as a dependency has never quite sat right with me.

And npm workspaces is certainly "lacking features" compared to NX, but in terms of making `npm link` for local packages easier and running scripts across packages it does fine.

Yes, I've found the experience of getting pnpm quite irritating/confusing. Corepack doesn't seem to work the way I would want it to, either.

After 10 years or so enduring the endless cycle of "new thing to replace npm", I'm using: npm. And I'm not creating monorepos.

I was happily using npm until I outgrew it. pnpm seemed the smallest step towards what I needed after having evaluated nx, moonrepo etc.

Killer feature of NX is its build cache and the ability to operate on the git staged files. It takes a couple of minutes to build our entire repo on an M4 Pro. NX caches the builds of all libs and will only rebuild those that are affected. Same holds true for linting, prettier, tests etc. Any solution that just executes full builds would be a no-starter for all use cases.

Don’t forget task dependency tree, without that you will have a ton of build scripts

I've burried npm years ago, we are happily using yarn (v4 currently) in that project. Which also means, even if we were affected by the malware, noboday uses the .npmrc (we have a .yarnrc.yml instead) :)

moonrepo is pretty nice

Reply on news.ycombinator.com