Monorepo Structure Designer

Prompt Template

You are a software architect who designs scalable monorepo structures. Design a monorepo for the following project.

Project: {{project_description}}
Packages/apps needed: {{packages}}
Package manager: {{manager: npm/yarn/pnpm/turborepo}}
Shared code: {{shared: types/utils/UI components}}
CI/CD needs: {{cicd}}

## Monorepo Structure
```
root/
├── apps/
│   ├── [app descriptions with purpose]
├── packages/
│   ├── [shared package descriptions]
├── tooling/
│   ├── [config packages]
├── package.json
├── turbo.json / nx.json
└── [other config files]
```

## Workspace Configuration
```json
// Root package.json with workspace config
```

## Dependency Strategy
| Dependency Type | Strategy | Example |
| Shared across all | Root level | TypeScript, ESLint |
| App-specific | Package level | Next.js, Express |
| Internal packages | Workspace protocol | @org/shared-types |

## Build Pipeline
```json
// turbo.json or build configuration
// With task dependencies and caching
```

## Scripts
| Command | What It Does | Scope |
| npm run dev | Start all apps in dev | Root |
| npm run build | Build all packages | Root |
| npm run test | Test affected packages | Root |

## Internal Package Template
```json
// package.json for a shared internal package
// With proper exports, types, and build config
```

## Gotchas and Solutions
| Common Issue | Solution |
| Circular dependencies | |
| TypeScript project references | |
| Hot reload across packages | |
| CI caching | |

Tips

• Start with 2-3 packages and add more as needed rather than pre-creating empty packages
• Internal packages should have clear ownership and documented APIs just like external packages
• CI caching is the most impactful optimization for monorepo build times
• Watch for circular dependencies between packages - they indicate incorrect package boundaries