---
title: Bun and turbo
description: Run the PharmaFlow monorepo with bun workspaces and turbo tasks.
---

You run everything through bun and turbo from the repository root. Bun is the runtime and package manager, pinned to `1.4.3` in the root `package.json`, and turbo schedules the workspace tasks defined in `turbo.json`. Learn this map once and you will reach for the right command every time.

### Install with the pinned bun version

You install dependencies with bun workspaces covering `apps/*` and `packages/*`. The `packageManager` field pins `bun@1.4.3`, so check your version before you install.

```bash
bun --version
bun install
```

If your bun version differs, switch to 1.4.3 first. A mismatched runtime is the most common cause of lockfile churn and phantom install diffs, so keep every contributor on the pinned version.

### Know the five turbo tasks

You orchestrate the monorepo through five tasks in `turbo.json`: `build`, `typecheck`, `test`, `dev`, and `seed`. Builds depend on upstream builds via `dependsOn: ["^build"]`, while `dev` and `seed` never cache and `dev` runs persistently.

```bash
bun run build
bun run typecheck
bun run test
```

`build` emits `.next/**` outputs, `typecheck` skips `.next` and `*.tsbuildinfo` inputs, and `test` runs each workspace suite in dependency order. You rarely need `turbo run` directly; the root scripts wrap it for you.

### Start the apps you need

You pick how many apps to run from the root scripts in `package.json`. `dev:server` starts the Hono API from `apps/server/src/index.ts`, `dev:register` starts the Next.js register, `dev:knowledgebase` starts the docs site, `dev:marketing` starts the marketing site, and `dev:app` starts the server and register together through turbo filters.

```bash
bun run dev:server
bun run dev:register
bun run dev:knowledgebase
bun run dev:app
```

Use `dev:server` when you work on API features, `dev:register` when you work on the counter UI, and `dev:app` when you test the full sale flow end to end. The bare `dev` script runs every workspace dev task, which is heavier than you usually want.

### Build and check quality gates

You verify the same gates CI runs with `lint`, `format:check`, and `typecheck` from the root. The server deploys through the Vercel entry `apps/server/api/index.ts`, which imports `app` from `apps/server/src/index.ts` and exports it through `handle` from `hono/vercel`, configured by `apps/server/vercel.json`; there is no separate build step for it.

```bash
bun run lint
bun run format:check
bun run typecheck
```

Run these three before you open a pull request. Your commit and pull request conventions live in `.patterns/docs.md`, and the repository map is in [Getting started](/getting-started) if you are still orienting.

### Regenerate the API reference

You rebuild the OpenAPI reference that lives next to the docs with `docs:api`, which maps to the `openapi` script in `apps/server/package.json` and runs `apps/server/scripts/generate-openapi.ts`. The script writes `apps/knowledgebase/openapi.json`, so you run it from the root after every route change:

```bash
bun run docs:api
```

### Keep lint and format clean

You lint with oxlint and format with oxfmt, both pinned in the root `package.json` devDependencies. The `lint` script fails on any warning, so treat warnings as errors while you code.

```bash
bun run lint
bun run format
bun run format:check
```

Run `format` to fix your tree and `format:check` to verify it in CI style. Formatting covers the whole monorepo from the root, so one command keeps the server, register, and docs consistent.

### Next steps

Set up your test loop in [Testing](/tooling/testing), then reset local data with the seed command when your checkout drifts.