Consider a monorepo for Atomic-Data-Browser and Rust

[joepio]

We have:

• atomic-data-docs, containing just documentation. The goal of the issue tracker is to discuss the spec. It should probably be kept separate for this reason.
• atomic-data-rust, containing atomic-server, a CLI and a rust library. These are highly interdependent (or at least, cli and server depend on lib)
• atomic-data-browser, which also contains the react and typescript libraries.

Reasons to combine atomic-data-rust and atomic-data-typescript in a single repo:

• Easier to perform integration tests / CI with multiple changing parts
• Easier to contain the host browser assets in the server Host the data-browser assets / JS bundles #185
• Better discoverability of other parts of the stack
• Users might find it easier to drop an issue in one repo, instead of having to decide which part is failing if they see an error.

Reasons not to:

• The project will be seen more as one big stack, instead of as a modular stack with an open standard
• Issues for both front-end and back-end will be less separated.

Steps:

• Move open PRs
• Move issues https://jloh.co/posts/bulk-migrate-issues-github-cli/
• Move data
• Combine github actions / workflows
• Remove build_server.sh script
• Move Github Site for @tomic/lib NPM TS docs
• Update Browser readme
• Update Server readme
• Update Contribute.md
• Update gitignore
• Fix docker build
• Fix release script

[jonassmedegaard]

I'd recommend to only use a monorepo for projects released in lockstep.

I find it annoying and semantically confusing to "jump in time" between the release tags of the contained parts within a single git repo.

[joepio]

In practice I'm using a lock-step release schedule / deployment. Both versions are kept in sync, so this already is something I'm dealing with. If it was a single repo, this would be easier.

I'm not sure if I follow the jumping in time bit - this should not be necessary at any moment if this was a monorepo

[jonassmedegaard]

if you released Rust crates in even weeks and Node modules in uneven weeks, tagged rust-vX.Y.Z and node-vX.Y.Z, then at the node-vX.Y.Z tag the Rust code would be in the middle of development.

E.g. https://github.com/rollup/plugins uses such interleaved release style.

But yes, if all parts are released in lockstep that is not an issue.

[jonassmedegaard]

I just noticed how https://github.com/withastro/snowpack.git tags both module-specific releases and monorepo releases.
I find that a sensible approach - assuming all module releases are kept stable for monorepo releases.

What I mean is, even if now you expect to only need to release all in lockstep, then there's room for doing minor releases of individual modules in-between those lockstep releases - just make sure to use a branch for things that might get in the way of any release in any module.