Thank you for your interest in contributing to VibeCode! This guide will help you understand how to set up your development environment, follow our coding standards, and submit contributions.
VibeCode is an AI-native IDE and Agent Orchestrator built with:
- Frontend: Next.js 14 App Router with React 19 and TypeScript
- Desktop Shell: Tauri 2.9.1 (macOS, Linux, Windows)
- Backend Infrastructure: Docker, Kubernetes, PostgreSQL, Redis/Valkey
- AI Models: 321+ models via OpenRouter and Ollama
The application provides AI-powered development tools, agent orchestration, and advanced IDE features.
Before you begin, ensure you have:
- Node.js: >= 18.18.0 and < 25.0.0
- npm: >= 9.0.0
- Git: Latest version
- Docker Desktop: Latest (for running backend services)
- macOS/Linux/Windows: For Tauri desktop builds
- Tauri CLI (for desktop builds):
npm install -g @tauri-apps/cli - Rust: If building Tauri for production
📚 Comprehensive Setup Guide: For detailed platform-specific installation instructions and version requirements, see docs/setup/PREREQUISITES.md.
✅ Automated Validation: Run
bash scripts/validate-prerequisites.shto check if your system meets all requirements.
🚀 Quick Setup: Want to get started quickly? Use the interactive setup wizard:
bash scripts/setup-wizard.shThe wizard will guide you through choosing the right deployment mode for your needs.
📖 Comprehensive Guide: For detailed installation instructions, see:
- Installation Master Guide - Complete installation guide covering all deployment modes
- Quick Start Checklist - Get running in under 5 minutes
- Deployment Decision Tree - Choose the right deployment mode
git clone https://github.com/ryanmaclean/vibecode.git
cd vibecodenpm installThe postinstall script will automatically ensure native binaries are available.
npm run devThis launches the Next.js development server on http://localhost:3000.
Always run tests with --maxWorkers=2 to avoid out-of-memory errors:
npm test -- --maxWorkers=2npm run build
npm startFor faster setup, use one of our automated scripts:
-
Docker Compose (recommended for most developers):
bash scripts/quick-setup-docker-compose.sh
-
Kubernetes (KIND) (for testing Kubernetes deployments):
bash scripts/quick-setup-kind.sh
All scripts support --dry-run to preview changes before executing.
vibecode/
├── src/
│ ├── app/ # Next.js App Router pages and layouts
│ │ ├── api/ # API routes (Next.js 14 route handlers)
│ │ ├── auth/ # Authentication pages
│ │ ├── chat/ # Chat and conversation pages
│ │ ├── settings/ # Settings pages
│ │ └── ... # Other feature pages
│ ├── components/ # Reusable React components
│ │ ├── error/ # Error handling (ErrorBoundary)
│ │ ├── navigation/ # Navigation components
│ │ └── ... # Feature-specific components
│ ├── hooks/ # Custom React hooks
│ ├── lib/ # Utility libraries and helpers
│ ├── middleware.ts # Express/Next.js middleware
│ ├── providers/ # Context providers
│ └── styles/ # Global styles
├── tests/
│ ├── unit/ # Unit tests
│ ├── integration/ # Integration tests
│ ├── e2e/ # End-to-end tests (Playwright)
│ └── k8s/ # Kubernetes deployment tests
├── platforms/ # Desktop platform-specific code
│ ├── macos/ # macOS Tauri build
│ └── ... # Other platforms
├── scripts/ # Build and setup scripts
├── docs/ # Documentation
└── package.json # Project configuration
git checkout -b feature/my-feature-nameFollow the naming convention: feature/, bugfix/, refactor/, or docs/ prefix.
- Make your changes in a feature branch
- Run tests frequently:
npm test -- --maxWorkers=2 - Check TypeScript:
npm run type-check - Lint your code:
npm run lint - Commit with clear, descriptive messages:
git add src/... git commit -m "feat: add new feature description"
- Push your branch to GitHub:
git push origin feature/my-feature-name - Open a Pull Request with a clear title and description
- Link related issues:
Closes #1234 - Ensure all CI checks pass
- Request review from team members
- Address feedback and re-request review
VibeCode uses Husky to run automated quality checks before each commit. These hooks catch issues locally before they reach CI, providing fast feedback and reducing failed builds.
Pre-commit hooks are automatically installed when you run npm install via the prepare script in package.json. Once installed, they run automatically on every commit attempt.
Two hooks are configured:
- commit-msg: Validates commit messages against conventional commits format
- pre-commit: Runs quality checks on staged files
When you commit code, the following checks run automatically:
- Check: Conventional commits format using commitlint
- Examples:
- ✅ Valid:
feat: add user authentication,fix: resolve memory leak - ❌ Invalid:
fixed bug,updated code,WIP
- ✅ Valid:
- Format:
type(scope?): description- Types: feat, fix, docs, style, refactor, test, chore, perf, ci, build, revert
- Scope: Optional, e.g.,
feat(api): add new endpoint
The pre-commit hook runs these checks on staged files:
- Secret Scanning: Detects accidentally committed secrets (API keys, tokens, passwords) using gitleaks
- Linting: ESLint checks on staged JavaScript/TypeScript files
- Type Checking: TypeScript compiler checks (
npm run type-check) - Format Checking: Prettier format validation on staged files
- Quick Tests: Fast unit tests related to changed files (not full test suite)
Performance: Hooks are optimized to run in < 30 seconds for typical changes by only checking staged files and running quick tests.
Local Pre-Commit (Fast Feedback):
- Lint staged files only
- Type-check entire codebase
- Run quick unit tests
- Format check staged files
- Secret scanning
CI (Comprehensive Validation):
- Full test suite (unit, integration, e2e)
- Full build verification
- Cross-platform testing
- Docker/Kubernetes deployment tests
- Security audit
- Coverage reporting
The pre-commit hooks are intentionally lightweight to provide fast feedback. CI runs more comprehensive checks that take longer.
You can run the pre-commit checks manually without committing:
# Run the full pre-commit script
bash scripts/pre-commit-tests.sh
# Run individual checks
npm run lint # ESLint
npm run type-check # TypeScript
npm run format:check # Prettier
npm test -- --maxWorkers=2 # Tests
npx gitleaks detect --no-git # Secret scanning
# Validate a commit message
echo "feat: my commit message" | npx commitlintIn rare cases where you need to bypass the hooks (e.g., emergency hotfix, WIP commit to save work), use the --no-verify flag:
git commit -m "wip: save work in progress" --no-verify--no-verify sparingly and only when absolutely necessary:
- Your code will still need to pass CI checks before merging
- Bypassing hooks can introduce issues that would have been caught locally
- Team reviewers may request fixes before approving your PR
When it's acceptable:
- Emergency hotfixes where speed is critical (still must pass CI)
- Saving WIP commits to avoid losing work (don't push to shared branches)
- Resolving git conflicts that temporarily break checks
When it's NOT acceptable:
- Avoiding legitimate linting or type errors (fix them instead)
- Skipping tests to save time (fix failing tests)
- Committing secrets or sensitive data (never commit secrets)
If hooks don't run automatically:
# Reinstall hooks
npm run prepare
# Verify installation
ls -la .husky/_/husky.sh # Should existIf pre-commit hooks fail:
- Read the error message carefully - it tells you what check failed
- Fix the reported issues in your code
- Stage the fixes:
git add <files> - Try committing again
Common issues:
- Lint errors: Run
npm run lintand fix reported issues - Type errors: Run
npm run type-checkand resolve type issues - Format issues: Run
npm run formatto auto-fix formatting - Test failures: Run
npm testto see which tests are failing - Secret detected: Remove the secret from your code (check gitleaks output)
If your commit message is rejected:
# Bad format
git commit -m "fixed bug" # ❌ No type prefix
# Good format
git commit -m "fix: resolve authentication bug" # ✅ Conventional format- Fast Feedback: Catch issues in seconds, not minutes (vs waiting for CI)
- Prevent Bad Commits: Stop problems before they reach the shared repository
- Consistent Code Quality: Enforce standards automatically
- Save CI Resources: Fewer failed CI builds means faster feedback for everyone
- Better Commit History: Conventional commits make history readable and enable automated changelog generation
Testing is critical to maintaining code quality. Always test your changes.
# All tests with memory limit
npm test -- --maxWorkers=2
# Unit tests only
npm run test:unit
# Integration tests
npm run test:integration
# End-to-end tests
npm run test:e2e
# Watch mode (development)
npm run test:watch
# Coverage report
npm run test:coverage
# Kubernetes tests
npm run test:k8s- Unit tests:
src/__tests__/module.test.tsorsrc/lib/__tests__/utility.test.ts - Integration tests:
tests/integration/feature.test.ts - E2E tests:
tests/e2e/feature.test.ts(Playwright)
Use Jest for unit and integration tests, Playwright for E2E:
// Unit test example
describe('MyComponent', () => {
it('should render correctly', () => {
render(<MyComponent />);
expect(screen.getByText('Expected Text')).toBeInTheDocument();
});
});
// API route test example
describe('GET /api/health', () => {
it('should return 200 with health status', async () => {
const response = await fetch('http://localhost:3000/api/health');
expect(response.status).toBe(200);
});
});- Strict Mode: TypeScript runs in strict mode for type safety
- Null Checks:
strictNullChecksis enabled; handle nullable values explicitly - Config: See
tsconfig.jsonfor full settings
- Flat Config: Uses ESLint 10 with flat config (
eslint.config.mjs) - Run Linting: Limited to critical paths by default
npm run lint
- React Version: Explicitly configured for React 19.2
- Utility-First: Use Tailwind utilities for styling
- Custom Colors: Add custom colors to
tailwind.config.tsif needed - Dark Mode: Support dark mode with Tailwind's dark mode utilities
- Files: Use kebab-case (
my-component.tsx,api-helper.ts) - Components: Use PascalCase (
MyComponent.tsx) - Functions: Use camelCase (
myUtilityFunction()) - Constants: Use SCREAMING_SNAKE_CASE (
MAX_RETRIES = 3)
All API routes follow Next.js 14 conventions:
// src/app/api/my-endpoint/route.ts
import { NextRequest, NextResponse } from 'next/server';
import { getServerSession } from 'next-auth';
export async function GET(request: NextRequest) {
// Authentication (if needed)
const session = await getServerSession();
if (!session) {
return NextResponse.json({ error: 'Unauthorized' }, { status: 401 });
}
// Your logic
const data = { message: 'Hello, World!' };
return NextResponse.json(data);
}
export async function POST(request: NextRequest) {
const body = await request.json();
// Your logic
return NextResponse.json({ success: true });
}Use getServerSession with authOptions from the auth configuration:
import { getServerSession } from 'next-auth';
import { authOptions } from '@/lib/auth';
const session = await getServerSession(authOptions);
if (!session?.user?.email) {
return NextResponse.json({ error: 'Unauthorized' }, { status: 401 });
}Use createServiceLogger for consistent logging:
import { createServiceLogger } from '@/lib/logging/service-logger';
const logger = createServiceLogger('MyService');
logger.info('Action started', { userId: session.user.id });
logger.error('Action failed', { error: error.message });Apply rate limits for public endpoints:
import { createAPIRateLimit } from '@/lib/rate-limit';
const rateLimit = createAPIRateLimit('endpoint-name');
const { allowed, response } = await rateLimit(request);
if (!allowed) return response;- Use
'use client'directive for client-side pages - Import lucide-react icons for UI elements
- Use ErrorBoundary for error handling
- Utilize AppNavigation for top navigation
- Sidebar layouts with
usePathname()for active state
Example:
'use client';
import { usePathname } from 'next/navigation';
import { Menu } from 'lucide-react';
import { ErrorBoundary } from '@/components/error/ErrorBoundary';
export default function Page() {
const pathname = usePathname();
return (
<ErrorBoundary>
<div className="flex">
{/* Navigation */}
{/* Content */}
</div>
</ErrorBoundary>
);
}- Keep components small and focused
- Export as named exports
- Use TypeScript for type safety
- Document complex props with JSDoc
interface MyComponentProps {
title: string;
onAction?: (data: string) => void;
}
export function MyComponent({ title, onAction }: MyComponentProps) {
return <div>{title}</div>;
}- Store custom hooks in
src/hooks/ - Use meaningful names prefixed with
use - Document hook dependencies and side effects
- Create directory:
src/app/my-feature/ - Create file:
src/app/my-feature/page.tsx - Add layout if needed:
src/app/my-feature/layout.tsx - Add tests:
tests/integration/my-feature.test.ts
- Create directory:
src/app/api/my-endpoint/ - Create file:
src/app/api/my-endpoint/route.ts - Implement GET/POST/PUT/DELETE handlers
- Add authentication and logging
- Write tests:
tests/integration/api/my-endpoint.test.ts
- Create file:
src/components/MyComponent.tsx - Export named component
- Add TypeScript types
- Write unit tests:
tests/unit/components/MyComponent.test.ts
🔧 Installation Issues: For comprehensive installation and setup troubleshooting, see:
- Installation Troubleshooting Guide - Flowcharts and solutions for common setup issues
- Run
bash scripts/diagnose-setup-issues.shto automatically detect and report common problems
If you encounter out-of-memory errors:
# Always use maxWorkers=2
npm test -- --maxWorkers=2# Check for type errors
npm run type-check
# Clear cache and rebuild
rm -rf .next
npm run build# Clear Next.js cache
rm -rf .next out
# Reinstall dependencies
rm -rf node_modules package-lock.json
npm install
# Rebuild
npm run build# Check specific paths (configured subset)
npm run lint
# Fix auto-fixable issues
npx eslint --fix src/app/api/agents ...- Jest tests limited to 2 workers to prevent OOM
- Use
--testTimeoutfor longer-running tests - Background tasks should avoid memory leaks
- Static optimization via Next.js build
- Tree-shaking enabled for production builds
- Docker builds use multi-stage approach
- Paginate large result sets
- Use indexes for frequently queried fields
- Cache expensive operations
- Never commit sensitive credentials (use environment variables)
- Validate all user input
- Sanitize HTML content
- Use HTTPS in production
- Follow OWASP guidelines
- Request code review for auth-related changes
- Documentation: Check
docs/directory for detailed guides- Installation Master Guide - Complete setup instructions
- Quick Start Checklist - Fast setup guide
- Installation Troubleshooting - Common problems and solutions
- Prerequisites Guide - Detailed dependency information
- Diagnostic Tools: Run
bash scripts/diagnose-setup-issues.shto identify common setup problems - Issues: Search existing GitHub issues or create a new one
- Discussions: Use GitHub Discussions for questions
- Team: Reach out to maintainers in Slack
This project is licensed under the MIT License. By contributing, you agree to license your work under the same terms.
- Next.js Documentation
- React Documentation
- TypeScript Documentation
- Tailwind CSS Documentation
- Tauri Documentation
- Jest Testing Documentation
Thank you for contributing to VibeCode! We appreciate your effort to improve the project.