mk

Overview ¶

License chores: the third-party notice file shipped with every release, and the npm production-dependency license policy.

These ran as scripts/gen-third-party-notices.sh and scripts/check-npm-licenses.mjs until they moved here. The shell half could not run on native Windows, and the whole point of tools/mk is that every contributor runs the same task code. Both still depend only on the standard library.

Command mk is BuildMax's task runner: build, test, run, and release chores for local development.

It is the implementation behind ./make and make.bat, which are one-line shims that forward here. The tasks live in Go rather than in shell so that macOS, Linux, and Windows contributors run the same code path — the previous bash + batch pair drifted apart because every task had to be written twice, and the batch half quietly stopped building the server, worker, gui, and desktop targets.

mk depends only on the standard library, so `./make test` still works when the rest of the module does not compile.

Release-archive verification: validate a GoReleaser archive's checksum and contents, and smoke-test the binary for the host platform.

This ran as scripts/verify-release-archive.go until it moved here, so that every binary entry point in the repository lives under cmd/ and a maintainer can verify a release the same way CI does: `./make release verify`.

Release notes: the GitHub Release body, composed from the version's CHANGELOG.md section and the standing install and alpha prose.

GoReleaser can only carry a static header and footer, so the body used to describe what BuildMax is and never what the version changed: v0.2.0-alpha.1 shipped a "recreate your database" upgrade note that appeared nowhere on its release page. Composing here keeps CHANGELOG.md the one place a change is written, and makes a missing section fail the release rather than publish an empty one.