fix(docker): ship builder node_modules in api/jobs runtime (pruned variant broke module resolution)#10
Conversation
…uned variant broke module resolution) whyc-api Cloud Run revision failed to start: 'Cannot find module reflect-metadata' from apps/api/dist/main.js. The 'prod-deps' stage (pnpm install --ignore-scripts + pnpm prune --prod, then COPY into runtime) produced an image where pnpm's isolated node_modules symlinks didn't resolve at runtime. Drop the prod-deps stage; copy node_modules + apps/<app>/node_modules from the 'builder' stage verbatim — the exact layout pnpm installed and built with, including the generated Prisma client. Larger image, but it actually runs. Same fix for Dockerfile.jobs (would hit the same MODULE_NOT_FOUND when the job executes). Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
|
You have reached your Codex usage limits for code reviews. You can see your limits in the Codex usage dashboard. |
|
Warning Rate limit exceeded
You’ve run out of usage credits. Purchase more in the billing tab. ⌛ How to resolve this issue?After the wait time has elapsed, a review can be triggered using the We recommend that you space out your commits to avoid hitting the rate limit. 🚦 How do rate limits work?CodeRabbit enforces hourly rate limits for each developer per organization. Our paid plans have higher rate limits than the trial, open-source and free plans. In all cases, we re-allow further reviews after a brief timeout. Please see our FAQ for further information. ℹ️ Review info⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (2)
✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
![gemini-code-assist[bot]](https://avatars.githubusercontent.com/in/956858?s=60&v=4){kind=small}
There was a problem hiding this comment.
Code Review
This pull request updates Dockerfile.api and Dockerfile.jobs to copy the full node_modules directory from the builder stage to the runtime stage, bypassing the previous production pruning step to resolve MODULE_NOT_FOUND errors. Feedback indicates that including all devDependencies increases the image size and security attack surface. It is suggested to use pnpm deploy or perform pruning within the builder stage to achieve a lean production image without breaking dependency resolution.
| COPY --from=builder --chown=whyc:nodejs /app/node_modules ./node_modules | ||
| COPY --from=builder --chown=whyc:nodejs /app/apps/api/node_modules ./apps/api/node_modules |
There was a problem hiding this comment.
Shipping the full node_modules from the builder stage includes all devDependencies (e.g., typescript, vitest, and the prisma CLI), which significantly increases the production image size and the security attack surface. While this addresses the module resolution issue, it is a suboptimal trade-off for production environments.
Improvement Opportunity:
The previous failure with pnpm prune --prod likely occurred because it was run in a separate prod-deps stage with only a subset of workspace files, which can break pnpm's symlink resolution. A more robust approach would be to run pnpm prune --prod directly in the builder stage after the build is complete (where all files are present), or use pnpm deploy --prod, which is the idiomatic way to create a self-contained production directory for a workspace package. This would keep the image lean and secure while ensuring all runtime dependencies are correctly resolved.
| COPY --from=builder --chown=whyc:nodejs /app/node_modules ./node_modules | ||
| COPY --from=builder --chown=whyc:nodejs /app/apps/jobs/node_modules ./apps/jobs/node_modules |
There was a problem hiding this comment.
Similar to Dockerfile.api, copying the entire node_modules directory from the builder stage includes unnecessary devDependencies. For a job runner, this increases pull times and cold starts on Cloud Run. Consider pruning dependencies within the builder stage or using pnpm deploy to maintain a minimal production footprint without breaking module resolution.
1 participant
whyc-apiCloud Run revision failed to start —Cannot find module 'reflect-metadata'fromapps/api/dist/main.js(health-check timeout →HealthCheckContainerError). Theprod-depsstage (pnpm install --ignore-scripts+pnpm prune --prod, copied into runtime) yielded an image where pnpm's isolatednode_modulessymlinks didn't resolve at runtime.Fix: drop
prod-deps; copynode_modules+apps/<app>/node_modulesfrom thebuilderstage verbatim — the exact layout pnpm installed & built with, including the generated Prisma client. Bigger image, but it runs. Same change toDockerfile.jobs(would hit the sameMODULE_NOT_FOUNDwhen thepipeline-kickoff-v2job executes).Dockerfile.webuntouched (Next.jsstandalonebundles its own node_modules).Merging re-triggers
deploy.yml; expected:deploy-apirevision healthy →deploy-web→smoke(R9).🤖 Generated with Claude Code