Modernize Monorepo Structure with pnpm Workspaces and Turborepo
Resolved 💬 13 comments Opened Apr 17, 2025 by alphajoop Closed Aug 7, 2025
💡 Likely answer: A maintainer (tibo-openai, collaborator)
responded on this thread — see the highlighted reply below.
Modernize Monorepo Structure with pnpm Workspaces and Turborepo
Summary
Propose to migrate the current npm-based monorepo to a more modern and efficient setup using pnpm workspaces and Turborepo for improved developer experience, build performance, and dependency management.
Current State
Currently, the Codex monorepo:
- Uses npm for package management
- Has manual coordination between packages
- Lacks efficient caching for builds and tests
- Requires manual configuration of cross-package dependencies
- Has inconsistent script naming across packages
Proposed Solution
Migrate to a modern monorepo setup with:
- pnpm as the package manager:
- Faster installation with content-addressable store
- Efficient disk space usage with symlinks
- Strict dependency management preventing phantom dependencies
- Built-in workspaces support
- Turborepo for build orchestration:
- Intelligent task scheduling and parallelization
- Local and remote caching for faster builds
- Dependency graph awareness
- Consistent script naming conventions
Benefits
- Faster CI/CD pipelines: Turborepo's caching can dramatically reduce build times
- Improved developer experience: Consistent commands across packages
- Better dependency management: pnpm prevents phantom dependencies
- Reduced disk usage: pnpm's content-addressable store saves significant space
- Simplified onboarding: Single command to install all dependencies
- Better cross-package development: Automatic linking of local packages
Implementation Plan
- Add
pnpm-workspace.yamlat the root - Convert existing
package.jsonfiles to be workspace-compatible - Add
turbo.jsonconfiguration for build pipelines - Update CI/CD workflows to use pnpm and Turborepo
- Update documentation and contributor guides
- Add proper workspace scripts for common operations
Example Configuration
# pnpm-workspace.yaml
packages:
- 'codex-cli'
- 'future-packages/*'// turbo.json
{
"$schema": "[https://turbo.build/schema.json",](https://turbo.build/schema.json",)
"pipeline": {
"build": {
"dependsOn": ["^build"],
"outputs": ["dist/**"]
},
"test": {
"dependsOn": ["build"],
"inputs": ["src/**/*.ts", "tests/**/*.ts"]
},
"lint": {},
"format": {},
"dev": {
"cache": false,
"persistent": true
}
}
}
13 Comments
Lgtm for pnpm as a first step, will accept a PR. Then we can consider Turborepo as a follow-up?
Also noticed there is a start on this by @crazywolf132 here:
https://github.com/openai/codex/pull/211
Could you coordinate so that this lands cleanly. Happy to review of course.
That sounds like a great approach! I'll prepare a PR for the pnpm migration first, focusing on:
Once that's stable and merged, we can evaluate Turborepo as a follow-up enhancement. This step-by-step approach will make the changes more manageable and easier to review.
I'll start working on the pnpm migration PR soon. Thanks for your support!
I would vote for Nx over Turborepo. :)
@BleedingDev ok and why do you prefer nx?
Nx Cloud, shared builds, recipes for migrations, MCP integration (great for agentic development!), interactive dependency graph (rather than static like Turborepo). :)
You can submit a proposal, @tibo-openai what do you think about it?
I'd say dont bother with Turbo or NX, considering there is not more than 1 package in this repo.
A simple pnpm-workspace will do just fine, and will not overcomplicate this
Happy for this PR to take over instead of mine.
I am going to close mine, and raise a pr tomorrow to replace Eslint and prettier with biome instead
@crazywolf132 Great idea, i also noticed we are using eslint version 8
And for your PR there were a lot of conflicts I think but we had the same goal.
Thank you for the feedback! We appreciate your suggestions for modernizing the monorepo structure. Please try again on the latest version of Codex CLI, as we're currently focused on the native/Rust implementation. If the issue persists, we'd be happy to consider improvements to the
codex-rs/implementation.