Welcome to the Land project! This document provides a high-level overview of the architecture and the core workflows that drive the application. Our system is composed of three primary components:
Common👨🏻🏭 (Rust Crate): The abstract core library. It defines the architectural "language" of the application through traits, data structures (DTOs), and a declarative Effect system. It has no knowledge of the final implementation.Mountain⛰️ (Rust Application): The native backend. It is a Tauri application that implements the abstract traits fromCommon, manages the native OS interactions, runs a gRPC server, and orchestrates theCocoonsidecar process.Wind🍃 &Sky🌌 (TypeScript UI): The frontend.Windis a re-implementation of the VS Code workbench services usingEffect-TS, providing the application logic for the UI.Skyis the declarative UI component layer (e.g., React, Vue) that renders the state managed byWind.Cocoon🦋 (TypeScript Application): A Node.js sidecar process managed byMountain. It is responsible for running extensions in a sandboxed environment and providing them with a high-fidelityvscodeAPI.
Communication between Mountain and Cocoon is handled via gRPC, while
communication between Mountain and Wind/Sky is handled via Tauri Events
and Commands.
-
Application Startup & Handshake
- Describes the complete end-to-end process of launching
Mountain, spawningCocoon, and establishing a stable, initialized state for both the UI and the extension host.
- Describes the complete end-to-end process of launching
-
- Details the flow from a user clicking a file in the explorer to the
content being read from disk by
Mountainand rendered in an editor byWind.
- Details the flow from a user clicking a file in the explorer to the
content being read from disk by
-
Invoking a Language Feature (Hover Provider)
- A key example of bi-directional communication, showing how an extension
in
Cocoonregisters a feature,Mountainorchestrates the request, and the result is displayed in theWindUI.
- A key example of bi-directional communication, showing how an extension
in
-
Saving a File with Save Participants
- Explains the advanced process of intercepting a save event, allowing an
extension in
Cocoonto modify a file (e.g., for formatting) beforeMountainwrites it to disk.
- Explains the advanced process of intercepting a save event, allowing an
extension in
-
Executing a Command from the Command Palette
- Illustrates the unified command system, showing how
Mountain's command registry can seamlessly dispatch execution to either a native Rust handler or a proxied command inCocoon.
- Illustrates the unified command system, showing how
-
Creating and Interacting with a Webview Panel
- Details the full lifecycle of extension-contributed UI, from
Cocoonrequesting a panel toMountainmanaging the native webview window and proxying messages back and forth.
- Details the full lifecycle of extension-contributed UI, from
-
Creating and Interacting with an Integrated Terminal
- A deep dive into native process management, showing how
Mountainspawns a PTY process and streams its I/O to both theWindfrontend and theCocoonextension host.
- A deep dive into native process management, showing how
-
Source Control Management (SCM)
- Outlines how the built-in Git extension in
CocoonusesMountainas a service to run nativegitcommands and then populates the SCM view in the UI with the results.
- Outlines how the built-in Git extension in
-
- Describes the end-to-end process of syncing user settings. It covers user authentication, fetching data from a remote store, performing a three-way merge, applying changes locally, and notifying all parts of the application.
-
- Explains the "Extension Development Host" model, where a second, isolated
instance of the application is launched to run tests, with the test
Cocooninstance remote-controlling the main UI.
- Explains the "Extension Development Host" model, where a second, isolated
instance of the application is launched to run tests, with the test
-
Tier-Gated Implementation Selection
- Describes how the
.env.Landfile propagates through Maintain's build script intoMountain'sbuild.rs, Cocoon's esbuild define map, and Sky's Vite define map — allowing each capability with more than one viable implementation (gRPC vs native, JS glob vsglobset, etc.) to live in the codebase simultaneously and be selected at build time without duplicating call sites.
- Describes how the
The following workflows are implemented in the codebase but are pending detailed documentation.
- Tree View Data Flow
- Describes how the UI requests children for a tree view node, and how
Mountainproxies this request to the correctTreeDataProviderinCocoon.
- Describes how the UI requests children for a tree view node, and how
- Custom Editor Lifecycle
- Details the process of opening a file in a custom editor, handling edits, saving custom document data, and managing backups and reverts.
- Debugging Session Lifecycle
- Outlines the flow from launching a debug configuration to
Mountainstarting a debug adapter, and how debug events (breakpoints, step, pause) are communicated between the UI,Mountain, andCocoon.
- Outlines the flow from launching a debug configuration to
- Task Execution
- Explains how tasks defined in
tasks.jsonor by extensions are discovered and executed, including how their output is piped to a terminal view.
- Explains how tasks defined in