Minimize impact of pnpm in build scripts

[joepio]

After merging Atomic Data Browser with AtomicServer, the new monorepo builds the JS assets instead of having them in the commits (which required manual work, yuck).

As a result of this, the build process depends on a JS package manager, in this case pnpm. This leads to pnpm being everywhere:

• build.rs (calls pnpm from terminal if assets are not found)
• Most github actions / workflows
• dockerfile (causing broken builds)
• all READMEs

I don't like this proliferation. Ideally, I'd make something like pnpm part of the build.rs, as an embedded crate thing. Just a rust crate that can build the js assets.

Sticking to pnpm

• Work right now
• Depends on node, requires extra build step

Add build artefacts in repo

This is what we did before we switched to the monorepo. Having JS artefacts in the commits every time anything changes bloats the repo, adds commits that have no semantic value, and increases dev-time complexity (because I sometimes forget to commit build artefacts!).

However it also means that building no longer requires node / pnpm which is great for everyone building Atomic-Server from source.

Using Bun

• Does not depend on node (yay), so we don't need node + pnpm dependencies in the CI
• It works, but I had some issues when configuring the actions. Don't remember exactly what it was, though.
• Bun has a build function, so it can serve as a replacement for vite build. However, I don't think as of now it can also replace vite as a development server. Bun used to have a bun dev command, but it's gone now. Also, I currently use pnpm --recursive to run the dev command in multiple projects at the same time - I want the browser to live-reload if I make changes to any of the libs. Not sure if that's possible with bun?
• bun test is crazy fast, which is great, but the test runner doesn't support many expect calls yet. (toHaveBeenCalledWith, toHaveBeenCalledTimes)

Turbopack

• Is written in Rust, so perhaps can be embedded in build.rs?
• I don't think it supports all the things that we need yet.

[joepio]

Deno v2

• Supports npm stuff, contrary to Deno v1
• Has its own FMT / lint tool. Less config.
• Written in Rust. Could become useful later?
• Small footprint, easier in CI than node + pnpm
• Fast!

But tried it, and:

• deno lint in data-browser seems to be stuck in a loop
• Can't see how I can run things recursively / in different folders
• other unknown issues?

EDIT: updated on Nov 12th