Repository navigation
Target reference
Every target at a glance, and what a machine needs to run them.
make without a target prints the annotated, colorized help, including the detected app, version and certificate status. Colors turn off automatically when stdout is not a terminal and honor NO_COLOR. make help-<target> (for example make help-rsync) prints extended help for a single target — options and worked examples where they help.
| Area | Targets |
|---|---|
| Release versioning |
version, changelog, tag
|
| Build |
build, dist, composer ARGS=..., npm ARGS=..., psalm [ARGS=...], reuse
|
| Local deploy |
rsync TARGET=..., cp TARGET=...
|
| Bundle analysis (module) |
bundle-report [ARGS=...], build-audit [ARGS=...]
|
| Checkout audit (module) |
consistency-audit [ARGS=...], build-verify [ARGS=...]
|
| App Store (module) |
csr, register, publish, sign, release, list-releases, list-releases-full, list-for-author, delete-release, ratings
|
| CI workflows (module) |
workflows-list, workflows-install W=..., workflows-update
|
| GitHub CLI (module) | gh-install |
| Utility |
clean, dist-clean, self-update, dev-init, dev-clean, help, help-<target>
|
Targets marked [m] in the help are maintainer-only: they need repository write access and/or the App Store signing key. Everything else works for anyone who clones the app. The areas marked (module) come from the developer modules (make dev-init, see Workflows, App Store, Bundle analysis and Checkout audit); without the modules those targets simply do not exist — which keeps the help of a plain checkout down to build, deploy and utility.
make psalm runs composer psalm on the current composer image; install the dev tools once with make composer ARGS=install beforehand. ARGS is forwarded past composer's own options (composer psalm -- ...), so make psalm ARGS="--show-info=true" reaches psalm. Details on Building and packaging.
make bundle-report reports what a browser downloads when a page of this app opens, and which packages those bytes are made of. It reads the build output and nothing else, so make build comes first. make build-audit reads the half that never ships — bundler config, package.json, src/ — and prices what it finds there in the bytes the build delivers. Options, output and findings: Bundle analysis.
make consistency-audit holds the statements the metadata makes against each other and names what a release still needs; it reads metadata only, no build and no network. make build-verify copies the tracked files into a scratch tree outside the app, installs and builds them twice and compares the result against the build output the checkout carries, so it is the one analyser that needs the network and takes minutes. Details: Checkout audit.
All four analysers run in the throwaway Node container and are mounted in from the ncmake cache, so the host needs no Node toolchain and nothing is written into the app.
make gh-install sets up the official GitHub CLI package source and installs gh, following the upstream install guide. The package manager is auto-detected (apt, dnf5, dnf4, yum, zypper, pacman, apk, brew, conda); on Debian and Ubuntu the source is written in deb822 format with the signing key ASCII-armored inside the file and verified against the documented fingerprints. The target is idempotent and asks for privileges per step through sudo. gh is what PR=1 needs, see Workflows.
GNU make, git, curl, openssl, rsync, python3. Optional but recommended: xmllint (libxml2) for reading info.xml — ncmake falls back to grep when it is missing, so a bare CI runner works too. Optional: podman or docker for containerized builds (strongly recommended; without them use RUNTIME=bare and provide composer and npm yourself).
