Monorepo Support

ContextKit automatically detects monorepo structures and intelligently analyzes frontend and backend packages separately.

šŸ“¦ Supported Monorepo Tools

• Turborepo
• Nx
• Lerna
• pnpm/yarn/npm workspaces

How It Works

1. Automatic Detection

ContextKit scans for monorepo indicators:

  • turbo.json (Turborepo)
  • nx.json (Nx)
  • lerna.json (Lerna)
  • workspaces in package.json
  • packages/ or apps/ directories

2. Package Classification

Each package is automatically classified based on dependencies and structure:

Frontend Indicators

  • React, Vue, Angular dependencies
  • Next.js, Nuxt, Svelte
  • components/ directory

Backend Indicators

  • Express, Fastify, Koa
  • NestJS, Django, Flask
  • server.js, api/ directory

3. Scope Selection

When running ck analyze, you'll be prompted to select:

Frontend

Analyzes React/Vue/Angular packages only

Backend

Analyzes API/server packages only

Both

Generates separate standards for frontend and backend

Usage Examples

Interactive Mode

ContextKit will prompt you to select the scope:

contextkit analyze

Output: "Which part of the monorepo should we analyze? Frontend (2 packages), Backend (1 package), Both, or Current directory only"

Non-Interactive Mode

Use CLI flags to skip prompts:

contextkit analyze --scope frontendcontextkit analyze --scope backendcontextkit analyze --scope bothcontextkit analyze --package apps/admin

Directory Structure

When analyzing both frontend and backend, ContextKit generates separate standards:

.contextkit/
ā”œā”€ā”€ standards/
│   ā”œā”€ā”€ frontend/          ← Frontend-specific standards
│   │   ā”œā”€ā”€ code-style.md
│   │   ā”œā”€ā”€ testing.md
│   │   └── architecture.md
│   ā”œā”€ā”€ backend/           ← Backend-specific standards
│   │   ā”œā”€ā”€ code-style.md
│   │   ā”œā”€ā”€ testing.md
│   │   └── architecture.md
│   └── ...                ← Shared standards (glossary, etc.)
└── config.yml             ← Tracks analysis_scope: "both"

Best Practices

1. Analyze Both Separately

Use --scope both to generate separate standards. This ensures frontend patterns don't mix with backend patterns.

2. Update Config After Analysis

The config.yml file tracks which packages were analyzed, making it easy to re-run analysis later.

3. Share Standards Across Teams

Use ck publish to share your monorepo standards configuration with other teams.

Was this helpful?

Help us improve the documentation by sharing your feedback.