Welcome to Land! We are building a high-performance, resource-efficient, and
cross-platform code editor inspired by the architecture of VS Code, but
re-imagined with a native Rust backend and a typed TypeScript service layer.
Land is engineered with Rust and Tauri for the native backend
(Mountain) and TypeScript for all application logic (Wind, Sky, and
Cocoon). The product name is FIDDEE; Land is the repository and build
system name.
Our vision is to deliver a lightning-fast and deeply reliable editing experience with ~88% VS Code API compatibility, so existing extensions run unmodified while the editor itself stays lean, auditable, and open-source.
- ~88% VS Code API Coverage:
Cocoonimplements the fullvscode.*namespace shim — TextEditor, Workspace, SCM, Window, Language Server Protocol, Debug, Tasks, Authentication, TreeView, and more — so the majority of existing VS Code extensions run unmodified. - High-Performance Native Backend:
Mountainis written in Rust with Tauri, providing native speed for file I/O, search, process management, and a Tokio-based async runtime. IPC uses a customActionEffectsystem for structured error handling and composable side effects. - Node.js Extension Host with Full
vscodeShim:Cocoonruns standard VS Code extensions in a Node.js sidecar. It communicates withMountainvia gRPC (Vine protocol) for all privileged operations and with Sky via Tauri events for UI interactions. - Effect-TS Service Layer: ~36 Wind services wire the VS Code workbench to Land's native backend. Each service is a typed Effect layer; dependencies are injected at startup rather than imported as globals.
- OSC 633 Terminal Shell Integration: Integrated terminals emit OSC 633
sequences for command zone detection, prompt anchoring, and shell-integration
features.
ShellIntegration.rsinjects a per-terminal.zshrcshim at launch and restoresZDOTDIRcleanly on exit. - AES-256-GCM Extension Credential Encryption:
encryption:encrypt/encryption:decryptIPC handlers use a machine-stable key derived from the hardware UUID (SHA-256). Extension secrets stored viacontext.secretsare encrypted at rest and never leave the local machine. - Strongly-Typed gRPC IPC: All
Mountain↔Cocooncommunication is defined inVine.protoand generated viaprost-build. The contract is versioned in theVineelement and shared by both sides. - Tier-Gated Implementation Selection: Every subsystem (file system, IPC
routing, extension activation, telemetry) is switchable via PascalCase env
vars baked into the build.
TierIPC=NodeDeferredroutes calls Mountain-first with a Cocoon fallback; no rebuild required to switch at runtime.
Land's architecture is composed of several key components that work in concert to deliver a modern editing experience.
| Component | Role & Key Responsibilities | Primary Technologies |
|---|---|---|
Common (Rust) |
The Abstract Core Library. All abstract trait definitions, the ActionEffect system, and shared DTOs. No concrete logic; all other Rust elements depend on it. |
Rust |
Mountain (Rust) |
The Native Backend. Tauri application that implements Common traits. Owns all native OS operations, the Vine gRPC server, Cocoon process lifecycle, IPC dispatch, and the ~/.fiddee/ filesystem root. |
Rust, Tauri, Tokio, tonic (gRPC) |
Cocoon (TypeScript) |
The Extension Host. Node.js sidecar providing ~88% VS Code API coverage. Implements the full vscode.* namespace shim. Communicates with Mountain via gRPC for privileged operations and with Sky via Tauri events for UI. Boots with an async-first, direct-call model. |
TypeScript, Node.js, gRPC |
Wind & Sky (TypeScript) |
The UI Layer. Wind wires ~36 workbench services to Land's native backend using typed Effect layers. Sky (Astro 6) is the component layer that renders state. Both communicate with Mountain via Tauri IPC events. |
TypeScript, Effect-TS, Astro |
To understand how these components interact, please refer to the detailed
workflow descriptions in
Documentation/GitHub/Workflow.md.
The following provides a table of contents for these essential processes.
-
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
-
Opening a File from the UI
- 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
-
User Data Synchronization
- 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.
-
Running Extension Tests
- 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
The following workflows are implemented in the codebase but are pending detailed documentation.
- Tree View Data Flow
- Custom Editor Lifecycle
- Debugging Session Lifecycle
- Task Execution
While Cocoon provides high compatibility with the existing VS Code ecosystem,
our long-term vision includes Grove, a native Rust extension host. Grove
aims to provide a highly optimized, secure, and performant environment for
extensions written in Rust or compiled to WASM, drastically reducing the
overhead of a Node.js runtime and enabling deeper integration with Mountain.
Our codebase is organized into "Elements", each representing a distinct component or library with a clear purpose. Most Elements are managed as Git submodules within the main Land repository, allowing for independent development and versioning.
| Path | Component / Purpose | |
|---|---|---|
Land/Element/Common |
The Abstract Core Library (Rust). This is the architectural heart of the native backend. It contains no concrete logic, only trait definitions, the ActionEffect system, and shared Data Transfer Objects (DTOs). All other Rust components depend on it. |
|
Land/Element/Echo |
The High-Performance Task Scheduler (Rust). A complete Rust library that provides a structured concurrency runtime. It features a high-performance, work-stealing queue and is designed to be the core execution engine for all asynchronous tasks within Mountain. |
|
Land/Element/Vine |
The gRPC Protocol & Implementation. This element contains the .proto file defining the gRPC contract between Mountain and Cocoon. It also includes the generated code and the concrete Rust server/client implementations within the Mountain and Cocoon projects. |
|
Land/Element/Mountain |
The Native Backend Application (Rust). This is the main Tauri application. It implements the traits from Common, manages the application window, orchestrates native OS operations, hosts the gRPC server, and manages the lifecycle of all sidecar processes. |
|
Land/Element/Dependency/Microsoft/Dependency/Editor |
The VS Code Source Submodule. Contains a specific version of the Microsoft VS Code source code. This is a critical dependency used by Rest to build Cocoon's runtime and by Wind to leverage VS Code's core UI components and services. |
|
Land/Element/Rest |
The JS Bundler Configuration. This element contains the build scripts and configurations (e.g., for esbuild) used to bundle the necessary VS Code platform code from the Dependency submodule for Cocoon to consume. |
|
Land/Element/Output |
The Bundled JS Output. This directory is the destination for the bundled JavaScript artifacts created by the Rest build process. It is the code that Cocoon actually loads at runtime. |
|
Land/Element/Cocoon |
The Node.js Extension Host (TypeScript). A sidecar process that runs standard VS Code extensions. It is built entirely with Effect-TS and provides a high-fidelity vscode API, proxying privileged calls to Mountain via gRPC. |
|
Land/Element/Wind |
The UI Service Layer (TypeScript). A complete, Effect-TS native re-implementation of the VS Code workbench services. It runs in the Tauri webview and manages the entire state and logic of the user interface. |
|
Land/Element/Worker |
Web Worker Implementations. This element holds the source code for any dedicated web workers used by the Wind/Sky frontend for computationally intensive tasks. |
|
Land/Element/Sky |
The UI Component Layer (Astro). This project contains the actual UI components that render the editor, side bar, status bar, etc. It is driven by the state managed in the Wind service layer. |
|
Land/Element/Mist |
WebSocket Communication Logic. This component handles WebSocket communication. It can be implemented either as a native module within Mountain or as a separate sidecar. |
|
Land/Element/Maintain |
Project Maintenance & CI/CD. Contains development utilities, GritQL queries for automated refactoring, CI/CD pipeline configurations, and other maintenance scripts. |
|
Land/Element/Grove |
(Future Vision) The Native Rust Extension Host. A planned project to build a high-performance, secure extension host in Rust, capable of running extensions compiled to WASM or statically linked as a Rust library. |
This diagram illustrates the build-time and runtime interactions between the primary components of the Land application.
graph LR
classDef mountain fill:#f9f,stroke:#333,stroke-width:2px;
classDef cocoon fill:#ccf,stroke:#333,stroke-width:2px;
classDef wind fill:#9cf,stroke:#333,stroke-width:2px;
classDef common fill:#cfc,stroke:#333,stroke-width:1px,stroke-dasharray: 5 5;
classDef ipc fill:#ff9,stroke:#333,stroke-width:1px,stroke-dasharray: 5 5;
classDef build fill:#ddd,stroke:#666;
classDef data fill:#eee,stroke:#666;
subgraph "Build Time Process"
direction LR
VSCodeSource["VS Code Source (Dependency/Editor)"]:::build
RestBuild["JS Bundler (Rest Element)"]:::build
CocoonBundleJS(Cocoon Runtime JS):::data
SkyBuildProcess["Sky Build (Sky Element)"]:::build
SkyAssets(Sky Frontend Assets):::data
VSCodeSource --> RestBuild;
VSCodeSource -- Uses UI code --> SkyBuildProcess;
RestBuild --> CocoonBundleJS;
SkyBuildProcess --> SkyAssets;
end
subgraph "Runtime: **Land** Application"
subgraph "Native Backend (Rust)"
Mountain["**Mountain (Tauri App)**"]:::mountain
CommonCrate[**Common Crate**]:::common
TrackDispatcher[Track Dispatcher]:::mountain
VineGRPCServer[Vine gRPC Server]:::mountain
NativeHandlers["Native Logic Handlers"]:::mountain
ProcessMgmt["Process Management"]:::mountain
Mountain -- Uses --> TrackDispatcher
TrackDispatcher -- Routes to --> NativeHandlers
Mountain -- Implements traits from --> CommonCrate
Mountain -- Contains --> VineGRPCServer
Mountain -- Contains --> ProcessMgmt
end
subgraph "UI Frontend (Tauri Webview)"
WindServices["**Wind (Effect-TS Services)**"]:::wind
SkyUI["**Sky (UI Components)**"]:::wind
WindServices -- Drives state of --> SkyUI
end
subgraph "Extension Host (Node.js Sidecar)"
Cocoon[**Cocoon Process**]:::cocoon
VineGRPCClient[Vine gRPC Client]:::cocoon
VSCodeAPI[vscode API Shim]:::cocoon
Extension["Extension Code"]:::cocoon
Cocoon -- Contains --> VineGRPCClient
Cocoon -- Provides --> VSCodeAPI
VSCodeAPI -- Used by --> Extension
end
ProcessMgmt -- Spawns & Manages --> Cocoon
WindServices -- Tauri IPC (Commands & Events) --> TrackDispatcher
VineGRPCClient -- gRPC (Vine Protocol) <--> VineGRPCServer; class VineGRPCClient,VineGRPCServer ipc;
end
CocoonBundleJS -- Loaded by --> Cocoon;
SkyAssets -- Loaded by --> WindServices;
Important
The build is a two-step linear flow. Do NOT pull submodules recursively -- each submodule is managed independently on its own branch.
Step 1: Compile VS Code Source (mandatory - do this before Step 2)
Node 24 is required for this step. The exact version is pinned in
Dependency/Microsoft/Dependency/Editor/.nvmrc.
cd Dependency/Microsoft/Dependency/Editor
nvm use 24
git fetch --all
git reset --hard Parent/main
git clean -dfx
pnpm install
pnpm run compile
pnpm run compile-extensions-buildStep 2: Build Land Application
cd Land # back to repository root
export Trace=all Record=1 Disable=false
./Maintain/Debug/Build.sh --profile debug-electron-bundled| Element | Submodule Repository |
|---|---|
Common |
github.com/CodeEditorLand/Common |
Mountain |
github.com/CodeEditorLand/Mountain |
Sky |
github.com/CodeEditorLand/Sky |
Wind |
github.com/CodeEditorLand/Wind |
Cocoon |
github.com/CodeEditorLand/Cocoon |
Rest |
github.com/CodeEditorLand/Rest |
Output |
github.com/CodeEditorLand/Output |
Dependency |
github.com/CodeEditorLand/Dependency |
Editor |
github.com/CodeEditorLand/Editor (inside Dependency) |
Clone each submodule individually on its target branch. Do NOT use
git clone --recurse-submodules.
| Profile | Use Case |
|---|---|
debug-electron-bundled |
Full bundled Electron debug build |
debug-electron-unbundled |
Electron debug without bundling |
Run the build from the Land repository root after completing Step 1.
This project is released into the public domain under the Creative Commons CC0
Universal license. You are free to use, modify, distribute, and build upon
this work for any purpose, without any restrictions. For the full legal text,
see the LICENSE
file.
Stay updated with our progress! See
CHANGELOG.md
for a history of changes.
Land 🏞️ is proud to be an open-source endeavor. Our journey is significantly supported by the organizations and projects that believe in the future of open-source software.
This project is funded through NGI0 Commons Fund, a fund established by NLnet with financial support from the European Commission's Next Generation Internet program. Learn more at the NLnet project page.
| Land | PlayForm | NLnet | NGI0 Commons Fund |
|---|---|---|---|
|
|
|
|
|
This project would not be possible without the incredible work of the open-source community. We are especially grateful for the following foundational technologies and projects:
- Tauri: For providing a secure, performant, and resource-efficient framework for building our native desktop application with a web frontend.
- Microsoft Visual Studio Code: For open-sourcing their workbench UI and platform code, which provides the foundation for our user interface and extension host compatibility.
- Effect-TS: For enabling us to build a robust, type-safe, and declarative application with a powerful structured concurrency and dependency management system in TypeScript.
- Rust: For the performance, safety, and modern tooling that powers our entire native backend.
- Tokio & Tonic: For providing the asynchronous runtime and gRPC framework that are the backbone of our high-performance IPC.
- Astro: For its content-driven approach that allows
us to build a fast and modern user interface for the
Skycomponent. - PNPM: For efficient and reliable management of our JavaScript dependencies.
- and many many more...
We extend our sincere gratitude to the maintainers and contributors of these and all the other dependencies we use. ❤️
Project Maintainers: Source Open (Source/Open@Editor.Land) | GitHub Repository | Report an Issue | Security Policy