Surprised you haven't heard of or used lerna (with yarn workspaces), which is the defacto monorepo setup in JS world. I use it to maintain a bunch of monorepos and works pretty flawlessly.
It's honestly embarrassing that modern web development (an incredibly "dumb" network protocol at its core) doesn't have an easier onboarding/development process.
All of the "linking between projects" is exactly what lerna does with bootstrapping/hoisting, so I'm not sure where you're coming from when you say this doesn't address OP's problem.
This is exactly what it is, and it's not even shy about it. It literally calls npm or yarn under the hood (specified with the `npmClient` setting).
> All of the "linking between projects" is exactly what lerna does with bootstrapping/hoisting, so I'm not sure where you're coming from when you say this doesn't address OP's problem.
Yeah, here's a "super simple" lerna example: https://github.com/dan-kez/lerna-webpack-example
It only has about 7 config files before even adding any "real" code. Fun stuff.
There's a ton of stuff like versioning, linking, running scripts/commands, etc across the entire project that npm and yarn do not inherently support.
I definitely think lerna has warts but it provides a ton of functionality that you'd have to ducktape together on your own, which it looks like a lot of people are trying to do as evident by this entire thread...
Learna needed a new maintainer and is now moving to Nrwl who develops Nx and seems to be the better choice for future projects?
I set up several projects in a monorepo recently using Yarn 3, and while the end result was awesome, the path to success was dark and weedy.
It seemed I was constantly 95% of the way there, but some detail or another wasn't quite right. Yarn has no solution for this, because the problem is the integration of tooling. eslint, typescript, prettier, jest, relay, you name it. They each want to work together and integrate with each other in different ways, using various sources of truth, and so on. Then your IDE needs to adhere to the same protocols, but various extensions have different opinions about default configurations.
Along the way you really need to know your tooling deeply, or you're in for some suffering.
Relatively simple projects with full buy-in of Yarn 3's tooling are probably pretty easy. Once you get relatively complex though, I don't know, I don't think any of this is easy.
It does sound like Nx handles a bunch of this stuff for you, which I'd love to try out. I really like that Yarn isn't particularly opinionated though. Once I had things set up, there was very little to change or that could break. The scaffolding was fairly plain to see, easy to work with, and we owned it. With something like Nx where things reportedly "just work", I worry it would be an unsettling blend of black boxes and black magic making my tooling and code work... Until it didn't, at which point I'd wish I used something less opinionated.
I just wrapped up switching over to pnp though, and that '95% of the way there' line you mentioned rings a bell for me.
You’re right, most of it did work using node_modules as the linker, but I found things like having eslint configure itself from typescript inexplicably blew up and resolving those issues wasn’t trivial.
I mean, it was on and off work for a week or so, migrating a few apps and packages (including a react native app, that was a big part of the motivation and struggle in the migration in the first place), so all in all it was acceptable. And the productivity gain was more than worth it. It just wasn’t as trivial as we expected/hoped.