contributing-to-ide-projects

Contributing to IDE Projects

Comprehensive workflow for contributing major features to open-source IDE and coding tool projects (VS Code, Cursor, Windsurf, Tauri-based editors).

When to Use This Skill

• Contributing to IDE/editor projects
• Building coding assistant tools
• Adding features to Tauri desktop apps
• Multi-PR contribution campaigns
• Competitive feature analysis

Pre-Contribution Analysis

0. Gap Analysis (CRITICAL — Do This First!)

Before recommending ANY features, check what already exists in the codebase:

# Check existing components
ls -la src/components/
find src -name "*.tsx" -o -name "*.ts" | grep -E "(component|store)"

# Check existing stores
ls -la src/stores/

# Search for feature keywords
grep -r "StatusBar\|QuickOpen\|Terminal\|FileTree\|Git" src/

# Check existing UI elements
cat src/components/layout/AppFooter.tsx  # Often has status info
cat src/components/layout/RightSidebar.tsx  # Check sidebar tabs

User expectation: When asked "ada yang recommended lagi gak?" or "apa lagi yang bisa kita kontribusikan?", user expects you to check existing features first. User will explicitly ask "cek fitur skrng dulu apa semua itu blm ada?" if you skip this step.

Output format:

## ANALISA FITUR EXISTING

### Yang Sudah Ada:
- ✅ AI Chat Interface
- ✅ Settings Modal (Providers, Agents tabs)
- ✅ Left/Right Sidebar system
- ✅ Theme system

### Yang Belum Ada:
- ❌ File Tree
- ❌ Code Editor
- ❌ Terminal
- ❌ Git Integration

### Verdict:
SEMUA 9 PRs yang gue bikin itu BELUM ADA! ✅

1. Understand the Project

# Clone and analyze
git clone <repo>
cd <repo>

# Read core docs
cat README.md
cat CHANGELOG.md
cat package.json  # Tech stack
cat src-tauri/Cargo.toml  # Rust dependencies (if Tauri)

Key questions:

• What's the tech stack? (React/Vue/Svelte, Tauri/Electron, TypeScript version)
• What features exist? (README features section)
• What's the architecture? (monorepo, frontend/backend split)
• What's the contribution process? (CONTRIBUTING.md)

2. Competitive Analysis

Compare with competitors:

• Cursor (AI coding assistant)
• Windsurf (AI IDE)
• VS Code (standard IDE)
• GitHub Copilot (AI pair programmer)

Create feature matrix:

| Feature | Cursor | Windsurf | Target Project | |---------|--------|----------|----------------| | Code Editor | ✅ | ✅ | ? | | Terminal | ✅ | ✅ | ? | | File Tree | ✅ | ✅ | ? | | Git Integration | ✅ | ✅ | ? | | Search & Replace | ✅ | ✅ | ? |

Identify gaps:

• Essential features (must-have for professional use)
• Competitive features (match competitors)
• Unique features (differentiation opportunities)

3. Prioritize Contributions

Tier 1: Essential (CRITICAL)

• Features without which the IDE is incomplete
• Examples: File tree, terminal, code editor, Git integration

Tier 2: Competitive Edge

• Features that match competitors
• Examples: Search & replace, command palette, keyboard shortcuts

Tier 3: Unique Differentiators

• Features competitors don't have
• Examples: AI code review, automated testing, performance profiling

Prioritization criteria:

1. Impact (how much it improves the IDE)
2. Effort (time to implement)
3. Dependencies (what else needs to exist first)
4. User demand (GitHub issues, discussions)

Multi-PR Strategy

Why Multiple PRs?

• Faster reviews — Smaller PRs reviewed faster
• Independent features — Can merge separately
• Parallel work — Don't block on reviews
• Easier rollback — Isolate issues

Integration Strategy for Multiple Features

When adding multiple interdependent features (e.g., 9 IDE components):

Problem: Features depend on each other but need to be reviewed independently.

Solution: Placeholder-based integration system

1. Create layout/infrastructure PR first
2. Layout system with panel management
3. Keyboard shortcut routing
4. State management stores
5. Placeholder components for all features

1. Use placeholder components

``tsx const FileTreePlaceholder = () => ( <div className="h-full flex items-center justify-center p-4 text-center"> <div> <p className="text-sm font-semibold mb-2">File Tree</p> <p className="text-xs text-gray-500">PR #8 - Coming soon</p> </div> </div> ); ``

1. Document integration points clearly

```markdown ## Integration Points

### Current State (Placeholders) All panels show placeholder components. This allows:

1. Testing layout system independently
2. Merging layout before feature PRs
3. Easy feature integration when PRs merge

### Future Integration (When PRs Merge) Replace placeholders with actual components:

// Before const FileTreePlaceholder = () => <div>Coming soon</div>;

// After (when PR #8 merges) import { FileTree } from '@/components/ui/FileTree'; const renderLeftPanel = () => { case 'file-tree': return <FileTree />; } ```

1. Merge features incrementally
2. Layout PR merges first (with placeholders)
3. Feature PRs merge independently
4. Replace placeholders as features land
5. No blocking dependencies

Example (enowX-Coder session):

• PR #14: Layout system with placeholders for all 9 features
• PRs #6-#13: Individual features (File Tree, Terminal, Git, Search, Editor, etc.)
• Integration: FileTreePlaceholder → <FileTree /> when PR #8 merges

Benefits:

• ✅ Layout testable independently
• ✅ Features developed in parallel
• ✅ Clear "what's missing" view for users
• ✅ Smooth integration path
• ✅ No merge conflicts
• ✅ Reviewers can test layout without waiting for features

Pitfall to avoid: Don't create cross-branch dependencies. Each feature PR should work standalone (even if just showing placeholder in layout).

PR Organization

Phase 1: Quick Wins (1-2 hours each)

• Keyboard shortcuts
• Loading states
• Empty states
• UI polish

Phase 2: Core Features (2-4 hours each)

• File tree
• Terminal integration
• Command palette

Phase 3: Advanced Features (4-6 hours each)

• Code editor (Monaco/CodeMirror)
• Git integration
• Search & replace

Phase 4: Unique Features (5-8 hours each)

• AI code review
• Test generation
• Debugger integration

Branch Naming

feat/command-palette-keyboard-shortcuts
feat/loading-empty-states
feat/file-tree-sidebar
feat/terminal-integration
feat/monaco-code-editor
feat/git-integration
feat/search-replace
feat/ai-code-review

Pattern: feat/<feature-name> (kebab-case, descriptive)

Tauri + TypeScript + Rust Pattern

Architecture

project/
├── src/                    # Frontend (React/TypeScript)
│   ├── components/ui/      # React components
│   ├── stores/             # Zustand state management
│   └── lib/                # Utilities
└── src-tauri/              # Backend (Rust)
    └── src/
        ├── commands/       # Tauri commands
        ├── lib.rs          # Command registration
        └── main.rs         # Entry point

Implementation Pattern

For each feature:

1. Create Rust commands (if backend needed)
2. Create TypeScript store (state management)
3. Create React component (UI)
4. Test TypeScript compilation
5. Fix errors immediately
6. Commit and push

Step-by-Step: Adding a Feature

1. Create Rust Commands (Backend)

// src-tauri/src/commands/feature.rs
use serde::{Deserialize, Serialize};
use tauri::command;

#[derive(Debug, Clone, Serialize, Deserialize)]
pub struct FeatureData {
    pub id: String,
    pub value: String,
}

#[command]
pub async fn feature_action(param: String) -> Result<FeatureData, String> {
    // Implementation
    Ok(FeatureData {
        id: "1".to_string(),
        value: param,
    })
}

2. Register Commands

// src-tauri/src/commands/mod.rs
pub mod feature;

// src-tauri/src/lib.rs
tauri::Builder::default()
    .invoke_handler(tauri::generat