On a fresh checkout, bun run dev reliably fails on the first run. The app and API start, but the agent's bundler loses a race against prisma generate --watch:
agent:dev: Failed to bundle authored module "/home/.../apps/agent/agent/agent.ts".
agent:dev: Build failed with 1 error:
agent:dev: [UNRESOLVED_IMPORT] Could not resolve './internal/class' in ../../packages/db/src/generated/prisma/client.ts
agent:dev: - ../../packages/db/src/generated/prisma/client.ts
agent:dev: - ../../packages/db/src/index.ts
agent:dev: - agent/lib/model.ts
agent:dev: - agent/agent.ts
agent:dev: error: script "dev" exited with code 1
Because the dev task is persistent, turbo kills the whole pipeline when it fails — nothing is left running, and the "fix" is just to run bun run dev again after the generation has settled.
Reproduce:-
cp .env.example .env -> fill the three required values
bun install
docker compose up -d
bun run db:deploy
bun run dev # agent fails on the first run
Root cause:-
-
packages/db/package.json dev is prisma generate --watch, which rewrites the whole src/generated/prisma/ tree on start (and on every schema change).
-
apps/agent/package.json dev is eve dev --no-ui, which bundles agent.ts → @crm/db → the generated client at startup.
-
Turbo's dev task (root turbo.json) is cache: false, persistent: true with no dependsOn, so all three start concurrently. The agent reads client.ts while prisma is mid-write of the internal/ directory (gitignored, regenerated in place).
This is dev-only: the build path is safe, because @crm/db's build is a one-shot prisma generate and agent's build has dependsOn: ["^build"].
Impact:-
Every fresh-clone developer hits this as their very first command, and the failure is silent in the wrong direction — the pipeline dies, but only after the app and API have already announced they're up.
Suggested fix directions
-
Ordering — in apps/agent/turbo.json, make dev depend on the one-shot generate:
"dev": { "dependsOn": ["@crm/db#db:generate"], ... }
This closes most of the window (the agent bundles against a complete tree);
and also note that it does not fully eliminate it, because prisma generate --watch re-runs an initial generation when it starts.
-
Robustness — wrap the agent's dev script to retry bundling once on failure, or delay eve dev until prisma generate has produced a complete tree (e.g. a readiness check on src/generated/prisma/internal/class.ts).
-
Test — a CI job that runs bun run dev (or the agent's dev script) once on a fresh checkout would pin this permanently.
On a fresh checkout, bun run dev reliably fails on the first run. The app and API start, but the agent's bundler loses a race against prisma generate --watch:
agent:dev: Failed to bundle authored module "/home/.../apps/agent/agent/agent.ts".
agent:dev: Build failed with 1 error:
agent:dev: [UNRESOLVED_IMPORT] Could not resolve './internal/class' in ../../packages/db/src/generated/prisma/client.ts
agent:dev: - ../../packages/db/src/generated/prisma/client.ts
agent:dev: - ../../packages/db/src/index.ts
agent:dev: - agent/lib/model.ts
agent:dev: - agent/agent.ts
agent:dev: error: script "dev" exited with code 1
Because the dev task is persistent, turbo kills the whole pipeline when it fails — nothing is left running, and the "fix" is just to run bun run dev again after the generation has settled.
Reproduce:-
cp .env.example .env -> fill the three required values
bun install
docker compose up -d
bun run db:deploy
bun run dev # agent fails on the first run
Root cause:-
packages/db/package.json dev is prisma generate --watch, which rewrites the whole src/generated/prisma/ tree on start (and on every schema change).
apps/agent/package.json dev is eve dev --no-ui, which bundles agent.ts → @crm/db → the generated client at startup.
Turbo's dev task (root turbo.json) is cache: false, persistent: true with no dependsOn, so all three start concurrently. The agent reads client.ts while prisma is mid-write of the internal/ directory (gitignored, regenerated in place).
This is dev-only: the build path is safe, because @crm/db's build is a one-shot prisma generate and agent's build has dependsOn: ["^build"].
Impact:-
Every fresh-clone developer hits this as their very first command, and the failure is silent in the wrong direction — the pipeline dies, but only after the app and API have already announced they're up.
Suggested fix directions
Ordering — in apps/agent/turbo.json, make dev depend on the one-shot generate:
"dev": { "dependsOn": ["@crm/db#db:generate"], ... }
This closes most of the window (the agent bundles against a complete tree);
and also note that it does not fully eliminate it, because prisma generate --watch re-runs an initial generation when it starts.
Robustness — wrap the agent's dev script to retry bundling once on failure, or delay eve dev until prisma generate has produced a complete tree (e.g. a readiness check on src/generated/prisma/internal/class.ts).
Test — a CI job that runs bun run dev (or the agent's dev script) once on a fresh checkout would pin this permanently.