Workspace workflows and deployment

Run complete or focused lifecycle commands, build applications independently, and diagnose workspace ownership and installation.

Run root workflows

From the workspace root:

brix install
brix dev
brix check
brix test
brix build
brix ci
brix verify

brix dev runs development projects in parallel. Check, test, build, and verify preserve library dependency order and skip an external member's missing phase scripts. brix ci performs only the clean, lockfile-exact root installation; brix verify is the complete diagnosis, check, test, and build gate for an installed workspace.

Select one project

Select a unique member by basename, package name, or path:

brix doctor#checkout-bff
brix check#commerce-contracts
brix test#checkout-bff --project node
brix build#apps/checkout-bff
brix start#checkout-bff

An existing workspace-relative test path selects its owner automatically:

brix test apps/checkout-bff/src/features/checkout/route.test.ts -t "returns checkout"
brix test apps/checkout-bff/e2e/checkout.spec.ts -t "places an order"

A selection spanning multiple members is rejected. Focused node tests do not run the root Storybook catalog or provision browsers. Focused application commands currently prepare all Brix libraries, not only the selected app's transitive graph; account for that extra build work in pipelines.

Build and deploy independently

Build all projects from one revision with brix verify, or focus an application in its deployment pipeline:

brix build#checkout-bff
PORT=3000 brix start#checkout-bff

Deploy each application's own output and runtime configuration. Applications can deploy the same repository revision on different schedules, but one workspace intentionally shares one Brix version and lockfile. Projects requiring incompatible framework versions belong in separate workspaces.

Diagnose the workspace

brix inspect workspace --json
brix doctor --json
brix ci
brix verify

Confirm one root lockfile, direct workspace:* links, no application-to-application dependencies, unique package names and basenames, and separate output for every deployable member. Member node_modules directories may exist as part of the one root-managed isolated installation; members must not own nested lockfiles or standalone installs.

Continue with Storybook, publishing releases, and CLI commands.