Visual Studio Code - Code OSS

Overview

Visual Studio Code (Code - OSS) is a free, open-source code editor developed by Microsoft. This repository contains the source code for VS Code, released under the MIT license. The project combines web technologies with native app capabilities using TypeScript, Electron, and web APIs to deliver a lightweight yet powerful editor for developers across Windows, macOS, and Linux.

Project Structure

The codebase is organized into distinct functional areas:

• src/ - Main TypeScript source code organized in layered architecture
• build/ - Build scripts, CI/CD tools, and compilation infrastructure
• extensions/ - Built-in extensions (language support, themes, debugging tools)
• test/ - Integration tests and test infrastructure
• scripts/ - Development and build automation scripts
• resources/ - Static assets (icons, themes, configuration files)

Layered Architecture

VS Code follows a strict layered architecture from bottom to top:

1. Base Layer (src/vs/base/) - Cross-platform utilities and abstractions
2. Platform Layer (src/vs/platform/) - Services and dependency injection infrastructure
3. Editor Layer (src/vs/editor/) - Text editing engine with syntax highlighting and language services
4. Workbench Layer (src/vs/workbench/) - Main application UI and features
5. Code/Server Layers (src/vs/code/, src/vs/server/) - Platform-specific implementations

Entry Points

• Desktop (src/main.ts) - Electron main process for desktop application
• Server (src/server-main.ts) - Node.js server for remote development scenarios
• CLI (src/cli.ts) - Command-line interface

Key Technologies

• TypeScript - Primary language for type-safe development
• Electron - Desktop application framework
• Node.js - Server runtime
• Web APIs - Browser-compatible APIs for cross-platform code
• Gulp - Build task automation
• Mocha - Testing framework

Development Workflow

The project uses npm scripts for common tasks:

npm run compile          # Compile TypeScript
npm run watch           # Watch mode for development
npm run test-node       # Run unit tests
npm run smoketest       # Run smoke tests
npm run valid-layers-check  # Validate architecture layers

Extension System

VS Code includes 100+ built-in extensions in the extensions/ folder. Each extension follows the standard VS Code extension structure with package.json and TypeScript sources, contributing features through the Extension API.

Contributing

The project welcomes contributions through:

• Bug reports and feature requests on GitHub Issues
• Pull requests with code changes
• Documentation improvements
• Extension development

See CONTRIBUTING.md and the How to Contribute wiki page for detailed guidelines.

Architecture & Layered Design

VS Code follows a strict layered architecture that separates concerns and enables cross-platform compatibility. Each layer builds upon the one below it, with clear dependency rules preventing circular dependencies.

The Five-Layer Architecture

1. Base Layer (src/vs/base/)

Foundation utilities and cross-platform abstractions. Contains no dependencies on higher layers.

• common/ - Platform-agnostic utilities (arrays, async, events, lifecycle, URI handling)
• browser/ - Browser APIs (DOM manipulation, events, performance)
• node/ - Node.js APIs (file system, processes, crypto)

2. Platform Layer (src/vs/platform/)

Services and dependency injection infrastructure. Defines service interfaces and implementations without UI concerns.

• instantiation/ - Dependency injection container and service decorators
• registry/ - Extension point registry for plugins
• lifecycle/ - Application lifecycle phases (Starting, Ready, Restored, Eventually)
• commands/, configuration/, workspace/ - Core services

Dependency Injection Pattern

Services use constructor-based injection with decorators:

export const IMyService = createDecorator<IMyService>('myService');

export class MyServiceImpl implements IMyService {
  constructor(
    @ILogService private logService: ILogService,
    @IConfigurationService private configService: IConfigurationService
  ) { }
}

3. Editor Layer (src/vs/editor/)

Text editing engine with syntax highlighting and language services. Platform-independent core logic.

• common/ - Models, commands, language features, tokenization
• browser/ - Rendering, DOM integration, view management

4. Workbench Layer (src/vs/workbench/)

Main application UI, layout, and feature orchestration.

• common/ - Contribution model, lifecycle coordination
• browser/ - Layout system, parts (editor, sidebar, panel, statusbar)
• services/ - Workbench-specific services
• contrib/ - Feature contributions (git, debug, search, terminal)

5. Code/Server Layers (src/vs/code/, src/vs/server/)

Platform-specific implementations for Electron desktop and Node.js server.

Contribution Model

Features register themselves through the contribution registry:

registerWorkbenchContribution2(
  'myFeature',
  MyFeatureClass,
  WorkbenchPhase.AfterRestored
);

Contributions are instantiated at specific lifecycle phases, enabling lazy loading and performance optimization.

Key Architectural Principles

• No upward dependencies - Base cannot depend on Platform; Platform cannot depend on Editor
• Service-oriented - All cross-cutting concerns are services injected via DI
• Lifecycle-aware - Components respect startup phases and disposal
• Extensible - Registry-based contribution model for plugins
• Cross-platform - Abstractions separate platform-specific code

Editor Engine & Text Model

The editor engine is built on a three-layer architecture: the Text Model (data), the View Model (projection), and the View (rendering). This separation enables efficient handling of large files and complex visual features.

Text Model Layer

The TextModel (textModel.ts) is the core data structure holding all editor content. It uses a Piece Tree data structure (pieceTreeTextBuffer.ts) for efficient text storage and manipulation. Instead of storing text as a single string, the Piece Tree maintains a balanced tree of text chunks, enabling O(log n) insertions and deletions without copying the entire buffer.

Key responsibilities:

• Content Management: Stores text with BOM detection, EOL normalization, and RTL/unusual character tracking
• Edit Operations: Validates and applies edit operations with undo/redo support via EditStack
• Decorations: Manages inline decorations, bracket pairs, and guides through specialized text model parts
• Tokenization: Integrates with TokenizationTextModelPart for syntax highlighting (supports both traditional tokenizers and Tree-Sitter)

// Text model creation with language detection
const model = modelService.createModel(
  textBuffer,
  languageSelection,
  resource
);

View Model Layer

The ViewModel (viewModelImpl.ts) projects the text model into a visual representation. It handles:

• Line Projection: Wraps long lines based on viewport width and word breaks
• Cursor Management: Maintains cursor positions and selections via CursorsController
• Viewport Tracking: Manages which lines are visible and need rendering
• Decorations Projection: Converts model decorations to view-space coordinates

The ViewModel uses either ViewModelLinesFromModelAsIs (for very large files) or ViewModelLinesFromProjectedModel (for normal files with line wrapping).

View & Rendering Pipeline

The View (view.ts) orchestrates rendering through a coordinated pipeline:

1. Event Collection: Model changes trigger events collected by ViewModelEventDispatcher
2. Render Scheduling: Changes are batched and scheduled via EditorRenderingCoordinator
3. ViewPart Preparation: Each ViewPart (cursors, decorations, minimap, etc.) prepares render data
4. DOM Rendering: Parts render to DOM in a single coordinated frame

Loading diagram...

Cursor System

The CursorsController manages multiple cursors and selections. Each cursor tracks both model and view positions (important when lines wrap). The system supports:

• Multi-cursor editing: Up to a configurable limit (default 10,000)
• Selection tracking: Maintains selection state across edits
• Cursor rendering: ViewCursors renders primary and secondary cursors with smooth animations

Cursor changes flow through the event system: model edits trigger cursor validation, which emits ViewCursorStateChangedEvent, causing the view to re-render cursor positions.

Performance Optimizations

• Lazy Tokenization: Only tokenizes visible lines; uses Tree-Sitter for better accuracy when available
• Viewport Culling: Renders only visible lines and decorations
• Deferred Events: Batches decoration and content changes to reduce event emissions
• GPU Rendering: Optional GPU-accelerated line rendering for large files (ViewLinesGpu)

Workbench UI & Layout System

Architecture Overview

The workbench UI is built on a hierarchical layout system that manages the main application window and its resizable parts. The Workbench class extends Layout and orchestrates the creation and lifecycle of all UI parts. The layout uses a SerializableGrid to arrange parts in a tree structure, enabling flexible resizing and persistence.

Core Components

Parts are the fundamental building blocks of the workbench layout. Each part (titlebar, sidebar, editor, panel, statusbar, etc.) extends the Part class and implements ISerializableView. Parts are registered with the layout service and participate in the grid layout system.

Composites are specialized parts that can host multiple views. The Composite class manages a single active view at a time, with lifecycle methods: create(), setVisible(), layout(), and dispose(). PaneComposite extends this to manage a ViewPaneContainer with multiple collapsible view panes.

Grid Layout System

The layout uses a SerializableGrid that organizes parts in a tree of branch and leaf nodes:

• Branch nodes split space horizontally or vertically, containing child nodes
• Leaf nodes represent actual parts (editor, sidebar, panel, etc.)

The grid is created from a descriptor in createGridDescriptor(), which arranges parts based on visibility and position settings. The descriptor respects user preferences for sidebar position (left/right), panel position (bottom/right), and part visibility.

Layout Arrangement

The workbench arranges parts in this hierarchy:

Root (Vertical)
├── Title Bar
├── Banner (optional)
├── Middle Section (Horizontal)
│   ├── Activity Bar
│   ├── Sidebar (left/right)
│   ├── Editor + Panel (vertical split)
│   └── Auxiliary Bar (right/left)
└── Status Bar

The middle section uses arrangeMiddleSectionNodes() to handle complex arrangements based on panel position (bottom vs. right) and sidebar position. The editor area can be centered using centerMainEditorLayout().

State Management

Layout state is managed through ILayoutRuntimeState and ILayoutInitializationState. Runtime state tracks visibility, maximized parts, fullscreen mode, and focus. Initialization state handles view restoration, editor restoration, and layout preferences. State is persisted to storage and restored on startup.

Key Methods

• layout() - Triggers a layout pass, resizing all parts to fit the container
• toggleZenMode() - Hides parts and enters fullscreen for distraction-free editing
• setPanelPosition() / setSideBarPosition() - Reposition parts dynamically
• togglePartVisibility() - Show/hide individual parts
• resizePart() - Adjust part sizes via sash dragging

Responsive Behavior

The layout responds to window resize events, fullscreen changes, and configuration updates. Parts emit onDidChange events when their size preferences change, triggering grid reflow. The grid supports proportional layout, maintaining relative sizes when the container resizes.

Extension API & Host Communication

Overview

VS Code extensions run in a separate extension host process isolated from the main renderer process. Communication between the extension host and the main process happens through a bidirectional RPC (Remote Procedure Call) protocol built on top of message passing. This architecture ensures extensions cannot crash the editor and provides a clean API boundary.

Architecture

Loading diagram...

Message Passing Protocol

The foundation is IMessagePassingProtocol, a simple interface for sending and receiving binary buffers:

export interface IMessagePassingProtocol {
  send(buffer: VSBuffer): void;
  readonly onMessage: Event<VSBuffer>;
  drain?(): Promise<void>;
}

Different transports implement this interface:

• Node.js: Message ports or sockets
• Browser: Web Workers or iframes with MessagePort
• Electron: Native IPC channels

RPC Protocol Layer

RPCProtocol wraps the message passing protocol and implements IRPCProtocol. It handles:

1. Proxy Creation: getProxy<T>(identifier) returns a typed proxy object
2. Method Invocation: Calls to proxy methods are serialized as RPC requests
3. Request/Response Matching: Each request gets a unique ID; responses are matched back
4. Cancellation: Supports CancellationToken for async operations
5. Buffer Optimization: Efficiently serializes VSBuffer objects without copying

Proxy Identifiers

ProxyIdentifier<T> uniquely identifies a remote object. The system maintains two sides:

• Locals: Objects registered on the current side via set(identifier, instance)
• Proxies: Remote objects accessed via getProxy(identifier)

Type safety is enforced through TypeScript's Proxied<T> type, which transforms all methods to return Promise<Dto<ReturnType>>.

Extension Host Initialization

The extension host startup follows a handshake:

1. Extension host sends MessageType.Ready
2. Main process responds with IExtensionHostInitData (version, workspace, extensions list, telemetry)
3. Extension host sends MessageType.Initialized
4. RPC protocol becomes active

Extension API Surface

extHost.protocol.ts defines the contract between extension host and main process through two shape interfaces:

• ExtHostExtensionServiceShape: Methods the main process calls on the extension host (e.g., $activate, $resolveAuthority)
• MainThreadExtensionServiceShape: Methods extensions call on the main process (e.g., $registerCommand, $showInformationMessage)

The extension API (vscode namespace) is created by createApiFactoryAndRegisterActors, which instantiates all extension-facing services and registers them with the RPC protocol.

Key Design Patterns

Lazy Promises: LazyPromise defers resolution until needed, reducing memory overhead for many pending RPC calls.

URI Transformation: URIs are transformed when crossing process boundaries to handle remote scenarios (SSH, containers).

Serialization: Objects are JSON-serialized with special handling for VSBuffer and CancellationToken. Functions are dropped during serialization.

Responsive State Tracking: The RPC protocol monitors responsiveness; if the extension host doesn't acknowledge requests within 3 seconds, it's marked unresponsive.

Core Features & Contributions

VS Code's workbench is built on a modular contribution system. Each major feature is implemented as a self-contained contribution that registers itself with the workbench during initialization. These contributions provide the core functionality users interact with daily.

Files & Explorer

The Files contribution manages the file system explorer and file editing. It provides:

• File Explorer View – Hierarchical browsing of workspace folders with drag-and-drop support
• File Operations – Create, rename, delete, copy, and paste files with undo support
• Text File Editor – Opens and manages text files with encoding detection and auto-save
• File Decorations – Visual indicators for file status (modified, excluded, etc.)
• Working Copy Management – Tracks unsaved changes and handles file conflicts

Key services: IExplorerService, IFileService, file editor input factories.

Search & Replace

The Search contribution enables workspace-wide text and file searching with:

• Search View – Full-featured search panel with regex, case sensitivity, and whole-word options
• Search Results Tree – Hierarchical display of matches grouped by file
• Replace Preview – Side-by-side comparison before applying replacements
• Quick File Access – Fast file lookup via quick access providers
• Workspace Symbols – Search for code symbols across the workspace

Supports multiple search providers and integrates with notebook search.

Source Control (SCM)

The SCM contribution provides version control integration:

• Repository Management – Register and manage multiple SCM providers (Git, etc.)
• Changes View – Display staged, unstaged, and untracked changes
• Quick Diff – Inline diff decorations in the editor gutter
• History Graph – Visualize commit history and branches
• Input Box – Commit message editor with template support

Extensible through ISCMProvider interface for custom VCS implementations.

Debug

The Debug contribution delivers comprehensive debugging capabilities:

• Debug Sessions – Launch and manage debug sessions with breakpoints
• Variables & Watch – Inspect variables, expressions, and call stacks
• Debug Console – REPL for evaluating expressions during debugging
• Breakpoints – Line, conditional, logpoint, and data breakpoints
• Debug Toolbar – Step over, step into, continue, and stop controls
• Disassembly View – Low-level debugging with instruction-level stepping

Supports multiple debugger types via adapter protocol.

Terminal

The Terminal contribution integrates an embedded terminal:

• Terminal Instances – Create and manage multiple terminal tabs
• Shell Integration – Detect commands, working directory, and command output
• Terminal Profiles – Configure shell environments per platform
• Terminal Contributions – Extensible hooks for terminal features (find, links, etc.)
• Process Management – Handle PTY creation and process lifecycle

Built on xterm.js with GPU rendering support.

Chat & AI

The Chat contribution provides AI-powered assistance:

• Chat Sessions – Persistent conversation history and session management
• Chat Agents – Pluggable AI agents with slash commands and tools
• Chat Modes – Ask, Edit, and Agent modes for different interaction patterns
• Code Editing – AI-assisted code generation and refactoring
• Context Attachment – Include files, symbols, and debug info in prompts

Integrates with language models and supports tool use.

Notebook

The Notebook contribution enables interactive computing:

• Notebook Editor – Cell-based editing with markdown and code cells
• Kernel Management – Register and select execution kernels
• Cell Execution – Run cells with output rendering and error handling
• Notebook Renderers – Custom MIME type renderers for rich output
• Notebook Serialization – Save and restore notebook state

Supports multiple notebook formats and extensible renderer system.

Loading diagram...

Each contribution follows a consistent pattern: register services, create views, handle commands, and respond to lifecycle events. This modularity allows features to be independently maintained and extended through the extension API.

Language Services & Syntax Highlighting

VS Code's language services architecture provides a unified system for registering languages, tokenizing code, and delivering rich language features like syntax highlighting, semantic tokens, inlay hints, and code lenses.

Language Registration & Discovery

Languages are registered through the ILanguageService and LanguagesRegistry. Each language has an ILanguageExtensionPoint defining its ID, file extensions, aliases, and configuration file. The registry maintains fast lookup maps by language ID, MIME type, and name. When a language is registered, the system fires change events to notify subscribers.

Tokenization System

The TokenizationRegistry manages tokenization support for each language. It supports both eager registration (direct tokenization support) and lazy registration (factories that create support on-demand). The registry tracks color maps and fires change events when tokenization support is updated. Text models use ITokenizationTextModelPart to manage line tokens and semantic tokens separately.

Language Features Registry

The LanguageFeaturesService maintains separate registries for each language feature type: hover providers, completion providers, code lens providers, inlay hints providers, semantic tokens providers, and many others. Each registry is a LanguageFeatureRegistry that orders providers by priority and language selector matching. Providers are queried in priority order, allowing multiple providers to contribute to the same feature.

Semantic Tokens

Semantic tokens provide fine-grained syntax highlighting based on language semantics. The DocumentSemanticTokensProvider interface allows language servers to return token data with a legend mapping token types and modifiers to semantic meaning. The system supports both full document tokens and range-based tokens. Tokens are cached with result IDs to support efficient delta updates.

// Semantic tokens flow: Provider → Legend → Styling → Model
const styling = semanticTokensStylingService.getStyling(provider);
model.tokenization.setSemanticTokens(result, true);

Inlay Hints & Code Lenses

Inlay hints display inline information (parameter names, type hints) without modifying the document. The InlayHintsController queries providers for hints in visible ranges, debounces requests, and renders hints as injected text decorations. Code lenses work similarly, displaying actionable information above lines. Both systems support provider change notifications to trigger re-computation when hints become stale.

// Inlay hints are rendered as injected text decorations
const inlayHints = await InlayHintsFragments.create(
  languageFeaturesService.inlayHintsProvider,
  model,
  ranges,
  token
);

Architecture Diagram

Loading diagram...

Key Design Patterns

Provider Priority Ordering: Multiple providers can serve the same language. The registry orders them by priority, allowing language servers to override built-in providers.

Lazy Loading: Tokenization and language features use lazy factories to defer expensive initialization until actually needed.

Debouncing: Controllers debounce provider requests to avoid excessive computation during rapid edits.

Change Notifications: Providers can signal when their data becomes stale, triggering re-computation without full document re-analysis.

CLI & Remote Development

Overview

VS Code provides two complementary CLI systems: a Rust-based CLI for local and tunnel operations, and a Node.js-based remote server CLI for headless environments. The tunnel system enables secure remote access to VS Code through vscode.dev.

CLI Architecture

The CLI is split into two implementations:

Integrated CLI (IntegratedCli) - Bundled with VS Code desktop, handles file operations, extensions, and tunnels.

Standalone CLI (StandaloneCli) - Requires VS Code installation, provides core functionality without desktop dependencies.

Both share a common CliCore structure with editor options, troubleshooting flags, and global options. The command dispatcher routes to subcommands like tunnel, ext (extensions), serve-web, and status.

Tunnel System

The tunnel feature creates a secure, publicly accessible connection to a local VS Code instance via vscode.dev. The architecture involves:

1. Dev Tunnel Management (dev_tunnels.rs) - Manages tunnel lifecycle, authentication, and relay connections using Microsoft's tunnel service
2. Control Server (control_server.rs) - Handles RPC communication between client and server, manages code server processes
3. Port Forwarding (local_forwarding.rs) - Forwards local ports through the tunnel with privacy controls (public/private)
4. Authentication (auth.rs) - Device flow OAuth with Microsoft or GitHub accounts

Loading diagram...

Remote Server CLI

The remote server runs in headless environments (SSH, containers, WSL) and provides a CLI interface via server-cli.js. Key features:

• Pipe Communication - Connects to local VS Code through VSCODE_IPC_HOOK_CLI environment variable
• WSL Support - Bridges Windows and WSL environments via VSCODE_CLIENT_COMMAND
• File Operations - Open files, folders, diffs, and merges in the connected editor
• Extension Management - Install/uninstall extensions remotely
• Wait Markers - Synchronize file operations with editor readiness

Authentication Flow

The tunnel system uses device code flow for authentication:

1. User runs code tunnel
2. CLI requests device code from Microsoft/GitHub
3. User visits verification URI and enters user code
4. CLI polls for authorization completion
5. Access token stored locally for future tunnel sessions

Tokens are persisted in the launcher state directory and automatically refreshed before expiration.

Port Forwarding

Tunnels support TCP port forwarding with granular privacy controls:

• Public Ports - Accessible via vscode.dev to anyone with the tunnel URL
• Private Ports - Require authentication; accessible only to tunnel owner
• Protocol Support - HTTP, HTTPS, and raw TCP protocols

The PortForwarding system tracks active ports and synchronizes them with the relay service, enabling dynamic port management without tunnel restart.

Service Management

On Windows, macOS, and Linux, tunnels can run as system services:

• Install - Registers tunnel as background service with auto-start
• Uninstall - Removes service and stops tunnel
• Logs - Accesses service logs for debugging

Service management is platform-specific, with implementations in service_windows.rs, service_macos.rs, and service_linux.rs.

Platform Services & Dependency Injection

Overview

VS Code uses a service-oriented architecture with constructor-based dependency injection. Services are singletons that provide core functionality without UI concerns. The platform layer defines service interfaces and their instantiation logic, enabling loose coupling and testability across the codebase.

Core Concepts

Service Identifiers

Services are identified using unique decorators created with createDecorator():

export const ICommandService = createDecorator<ICommandService>('commandService');

export interface ICommandService {
  readonly _serviceBrand: undefined;
  executeCommand<R>(commandId: string, ...args: unknown[]): Promise<R>;
}

The _serviceBrand property is a TypeScript-only marker that prevents accidental service substitution.

Dependency Injection Pattern

Services declare dependencies as decorated constructor parameters. The InstantiationService automatically resolves and injects them:

export class MyServiceImpl implements IMyService {
  constructor(
    @ICommandService private commands: ICommandService,
    @IConfigurationService private config: IConfigurationService
  ) { }
}

The decorator stores metadata on the constructor, which the instantiation service reads during object creation.

InstantiationService

The InstantiationService is the DI container that manages service lifecycle and instantiation:

Loading diagram...

Key methods:

• createInstance(ctor, ...args) - Creates an instance with injected dependencies
• invokeFunction(fn, ...args) - Calls a function with a service accessor
• createChild(services) - Creates a child container inheriting parent services
• dispose() - Cleans up all created services

Service Registration

Services are registered globally using registerSingleton():

import { InstantiationType, registerSingleton } from '../../instantiation/common/extensions.js';

registerSingleton(IMyService, MyServiceImpl, InstantiationType.Delayed);

Instantiation types:

• Eager - Created immediately when a consumer depends on it
• Delayed - Created only when first accessed (preferred for performance)

Registry Pattern

The Registry provides a generic extension point mechanism for plugins:

export interface IRegistry {
  add(id: string, data: any): void;
  knows(id: string): boolean;
  as<T>(id: string): T;
}

Used for registering commands, actions, configuration schemas, and other extensibility points.

Core Platform Services

Commands - ICommandService executes registered commands with arguments and events.

Configuration - IConfigurationService manages user settings and workspace configuration.

Context Keys - IContextKeyService evaluates conditional expressions for UI visibility.

Lifecycle - ILifecycleService signals application phases: Starting, Ready, Restored, Eventually.

Actions - IMenuService manages menu contributions and action visibility based on context.

Service Hierarchies

Services can create child containers for scoped instances:

const childServices = instantiationService.createChild(
  new ServiceCollection([IMyService, customImpl])
);

Child services inherit parent services but can override them. Disposing a child doesn't affect the parent.

Best Practices

1. Always use decorators for service dependencies, never pass services as regular arguments
2. Prefer Delayed instantiation to reduce startup time
3. Implement IDisposable if your service holds resources
4. Use ServicesAccessor in command handlers to access services dynamically
5. Avoid circular dependencies - the instantiation service detects them but they indicate design issues

Testing & Build Infrastructure

Build System

VS Code uses Gulp as its primary build orchestrator, with TypeScript-based task definitions. The build pipeline is modular, with separate gulpfiles for different components:

• gulpfile.ts - Main entry point that orchestrates compilation, extensions, and Monaco editor
• gulpfile.compile.ts - Handles TypeScript compilation with optional mangling and minification
• gulpfile.extensions.ts - Builds built-in extensions
• gulpfile.hygiene.ts - Validates code quality and package.json consistency

Key build tasks:

npm run compile          # Fast development compile
npm run watch           # Watch mode for development
npm run compile-build   # Production build with mangling
npm run hygiene         # Code quality checks

The compilation system uses gulp-tsb (TypeScript builder) with source maps, and supports both standard TypeScript compilation and esbuild transpilation for faster builds.

Testing Infrastructure

VS Code maintains three complementary test suites:

Unit Tests (test/unit/)

• Run in Electron renderer environment with DOM and Node.js API access
• Execute via ./scripts/test.sh (Electron) or npm run test-browser (Playwright)
• Support debugging with --debug flag and filtering with --glob or --run options
• Browser tests run on Chromium and WebKit via Playwright

Integration Tests (test/integration/)

• API tests for extension host functionality
• Run against real builds or development sources
• Execute via scripts/test-integration.sh (Electron) or scripts/test-web-integration.sh (browser)
• Test extensions like TypeScript, Markdown, Git, and Emmet

Smoke Tests (test/smoke/)

• Automated UI tests for end-to-end validation
• Run against development builds or release builds
• Support Electron, web, and remote scenarios
• Execute via npm run smoketest

Test Execution

./scripts/test.sh                    # Unit tests in Electron
npm run test-browser                 # Unit tests in browsers
npm run test-node                    # Node.js unit tests
./scripts/test-integration.sh        # Integration tests
npm run smoketest                    # Smoke tests
./scripts/test.sh --coverage         # Coverage report

Tests can be filtered by glob patterns and debugged interactively. The integration test suite runs multiple extension-specific test suites sequentially, managing temporary user data directories and crash reporting.

Code Quality

The hygiene task validates:

• Package.json consistency across remote/, build/, and root
• ESLint rules via npm run eslint
• StyleLint rules via npm run stylelint
• TypeScript layer architecture via npm run valid-layers-check

Loading diagram...