Skip to main content

​
Overview

This guide covers the pull request (PR) process for contributing code to Visual Studio Code. Following these guidelines helps ensure your contributions can be reviewed and merged efficiently.
Before submitting a pull request, make sure you’ve read the How to Contribute guide and Coding Guidelines.

​
Prerequisites

Before creating a pull request:
1

Set Up Development Environment

Follow the How to Contribute guide to:
  • Fork and clone the repository
  • Install dependencies
  • Build from source
  • Run VS Code in development mode
2

Find or Create an Issue

Associate your PR with an existing issue, or create one first to discuss the proposed changes.
3

Create a Branch

Create a new branch from main for your changes:
git checkout -b fix/issue-12345

​
Before Submitting

​
Code Quality Checklist

Ensure your code meets these requirements:
  • Uses tabs for indentation (not spaces)
  • Follows naming conventions (PascalCase for types, camelCase for functions)
  • Includes JSDoc comments for public APIs
  • Externalizes user-facing strings with nls.localize()
  • Uses proper TypeScript types (avoids any)
See Coding Guidelines for details.
Run the build to check for TypeScript compilation errors:
yarn watch  # or npm run watch
Fix all errors before submitting.
Run the test suites to ensure nothing breaks:
# Unit tests
./scripts/test.sh
# or on Windows: .\scripts\test.bat

# Integration tests
./scripts/test-integration.sh
# or on Windows: .\scripts\test-integration.bat
Add new tests for:
  • New features
  • Bug fixes (reproduce the bug, then fix it)
  • Changes to existing behavior
Place tests in the appropriate location:
  • Unit tests: src/vs/*/test/ folders
  • Integration tests: test/ folder or extension tests
Verify no architectural layer violations:
npm run valid-layers-check

​
Keep Code Up to Date

Ensure your code is up to date with the main branch before submitting.
# Update your main branch
git checkout main
git pull upstream main

# Rebase your feature branch
git checkout your-feature-branch
git rebase main

​
Creating the Pull Request

​
PR Title

Write a clear, concise title that describes what the PR does:
  • Fix hover flickering in editor
  • Add support for workspace trust API
  • Improve performance of file search
  • Update TypeScript to 5.3

​
PR Description

Provide a comprehensive description following the template: 
## Summary
<!-- Brief description of what this PR does -->

## Related Issues
<!-- Link to related issues using #issue-number -->
Fixes #12345

## Changes
<!-- List the main changes made -->
- Added new API for workspace trust
- Updated documentation
- Added tests for edge cases

## Testing
<!-- How to test these changes -->
1. Open a workspace
2. Try the new trust feature
3. Verify the behavior matches expectations

## Screenshots/Videos
<!-- If applicable, add screenshots or videos showing the changes -->
The template ensures you include:
  • Associated issue: Link using Fixes #issue-number or Relates to #issue-number
  • Description of changes: What was changed and why
  • Testing instructions: How reviewers can verify the changes
  • Visual evidence: Screenshots or videos for UI changes

​
Draft vs Ready

Use draft PRs when:
  • Work is still in progress
  • You want early feedback
  • Tests are not yet passing
Mark as draft when creating:
Create pull request (dropdown) → Create draft pull request

​
PR Review Process

​
What to Expect

Once you submit your PR:
1

Automated Checks

CI/CD pipelines run automatically:
  • Build verification
  • Test execution
  • Code analysis
  • Layering checks
All checks must pass before the PR can be merged.
2

Team Review

VS Code team members will review your PR:
  • Code quality
  • Design decisions
  • Test coverage
  • Documentation
3

Feedback & Iteration

Address review feedback:
  • Make requested changes
  • Respond to questions
  • Push new commits
Don’t force-push after review starts - it makes it harder to see what changed.
4

Approval & Merge

Once approved:
  • Maintainer will merge the PR
  • Changes will appear in the next VS Code release

​
Response Time

The VS Code team reviews PRs as time permits. Larger changes may take longer to review. Be patient and responsive to feedback.
You can help speed up the process by:
  • Keeping PRs focused and reasonably sized
  • Providing clear descriptions and test instructions
  • Responding promptly to review comments
  • Following coding guidelines

​
Responding to Feedback

​
Making Changes

When reviewers request changes:
  1. Make the requested changes in your local branch
  2. Commit the changes with clear commit messages
  3. Push to your fork - the PR updates automatically
# Make changes
git add .
git commit -m "Address review feedback: improve error handling"
git push origin your-feature-branch
Avoid force-pushing (git push -f) after reviewers have started their review. This makes it difficult to see what changed in response to feedback.

​
Discussing Feedback

If you disagree with feedback or need clarification:
  • Ask questions: Use PR comments to discuss
  • Explain your reasoning: Share why you made certain choices
  • Be open to learning: Maintainers know the codebase well
  • Stay professional: Keep discussions respectful and constructive
Reviewer: “Consider using a Map instead of an object here for better performance.”You: “Thanks for the suggestion! I chose an object because:
  1. The keys are always strings in this case
  2. The data set is small (< 10 items)
  3. An object is more ergonomic for this use case
However, if you think a Map would be better for consistency with other parts of the codebase, I’m happy to change it.”This shows you:
  • Considered the feedback
  • Explained your reasoning
  • Remained open to changing

​
Common Issues

​
Build Failures

If CI builds fail: 
# Check for type errors locally
yarn watch
Fix all compilation errors before pushing again.
# Run tests locally
./scripts/test.sh

# Run specific test
./scripts/test.sh --grep "test name"
Ensure all tests pass in your local environment.
# Check for layer violations
npm run valid-layers-check
Fix any violations by adjusting imports or moving code.
# Update from main and resolve conflicts
git checkout main
git pull upstream main
git checkout your-feature-branch
git rebase main
# Resolve conflicts, then:
git rebase --continue
git push -f origin your-feature-branch

​
PR Not Getting Attention

If your PR hasn’t received a review:
1

Ensure All Checks Pass

Reviewers prioritize PRs with passing CI checks.
2

Check PR Size

Very large PRs take longer to review. Consider splitting into smaller ones.
3

Verify Description

Make sure you’ve filled out the PR template completely.
4

Be Patient

The team reviews as time permits. Avoid repeatedly pinging for reviews.

​
Best Practices

​
Keep PRs Focused

One PR should address one issue or feature. This makes reviews faster and reduces the chance of merge conflicts.
✅ Good: "Fix hover flickering in editor"
❌ Bad: "Fix hover flickering, update TypeScript, and refactor workspace code"

​
Write Clear Commit Messages

Commit messages should explain the “why” not just the “what”: 
Fix hover flickering caused by rapid redraws

The hover widget was being destroyed and recreated
on every mousemove event, causing flickering.
Now we reuse the same widget instance.

Fixes #12345

​
Document Breaking Changes

If your PR introduces breaking changes, clearly document them in the description and consider if they’re necessary.
Breaking changes should:
  • Be discussed in the related issue first
  • Include migration guidance
  • Be clearly marked in the PR description

​
Test Thoroughly

Before submitting:
  1. Manual testing: Actually use the feature you built
  2. Automated tests: Run the full test suite
  3. Edge cases: Test unusual scenarios
  4. Performance: Ensure no performance regressions
  • Feature works as expected
  • Existing features still work
  • All unit tests pass
  • All integration tests pass
  • No console errors or warnings
  • Works across different operating systems (if applicable)
  • Performance is acceptable

​
After Your PR is Merged

​
Cleanup

Once merged, you can: 
# Delete your local branch
git checkout main
git branch -d your-feature-branch

# Delete remote branch
git push origin --delete your-feature-branch

# Update your fork
git pull upstream main
git push origin main

​
Track Your Contribution

Your changes will:
  • Appear in the next VS Code release
  • Be included in the release notes (for significant changes)
  • Be attributed to you in the git history
Check the release notes to see when your changes ship!

​
Additional Resources

How to Contribute

Getting started guide

Coding Guidelines

Code style standards

Issue Triaging

Understanding issue workflow

Wiki

Comprehensive documentation

​
Questions?

If you have questions about the PR process:
Thank you for contributing to VS Code! Every contribution, large or small, helps make VS Code better for everyone.