Design workspaces support

[zkat]

We need to design what workspaces will look like in ds. We should discuss what needs need to be fulfilled and examine the space a bit to see what others have done and how it can be improved on.

Some things I'd really like to have:

• Easy running of commands in sub-packages.
• Nested workspaces.
• Central version management for shared packages.
• Easy cross-subpackage dependency definitions (don't just rely on paths, maybe? -- I think pnpm does an interesting bit here, but maybe Yarn's approach of plain version definitions is better?).
• Look at https://bit.dev/ for more inspiration on monorepo management.
• As a stretch goal, we should have Lerna-like features for publishing subpackages.

[evocateur]

I'd love to help out, where I can. I've got, uh, a little experience with these monorepo thingies. (A well-trained autocomplete too, heh)

Some initial thoughts, largely at random:

Nested workspaces

What does this goal entail, exactly? Packages nesting inside other packages seems like a recipe for extreme ambiguity/confusion. If you're talking just package definitions at different levels of the directory tree without overlap, then consider my concern "old man yells at cloud" and carry on.

Central version management for shared packages

In my experience, I see a lot of folks opting for Lerna's "independent" versioning mode right off the bat (when in fact they often might not need it). I tend to prefer Lerna's default "fixed"/"unified" versioning, but I've often yearned for a hybrid mode that would allow a subset of packages to bump majors without the entire tree following in lockstep.

Anyway, interested to see where this goes!

[zkat]

@evocateur sorry, what I meant be central version management was versions of external dependencies. So if most of your packages rely on anyhow, you can define a single version of anyhow at the toplevel, and all the workspace packages will just use that.

In Cargo terms, it might look like:

# toplevel Cargo.toml
[central-dependencies]
anyhow = { version = "^1.0.25" }

# ./packages/my-subpackage/Cargo.toml
[dependencies]
anyhow = { central-version = true }

And then, if you try and publish that package, it slurps up whatever the defined spec in the toplevel one is and puts it in as the version it will depend on.

[zkat]

p.s., @evocateur I would love to hear what you think about bit.dev's workflows and what you think is worth pulling in.

[evocateur]

@zkat Oh, hah, sorry for diving down the wrong rabbit-hole on that one.

I gotta say, I'm really liking the progress pnpm has been making lately on the monorepo front. I'm half-convinced to use pnpm in Lerna's own monorepo and focus on lerna publish and lerna version (the most interesting parts) exclusively...

I will have to carve out some time to explore bit.dev! A blog post from 2018 seems like as good a starting place as any...