Sky - Deep Dive

Sky renders the complete editor interface inside the Tauri webview using Astro, consuming state and services from the Wind service layer. the internal architecture, module inventory, Sky Bridge event routing, build optimization strategy, data flow, integration points, and configuration.

Architecture

Sky is organized into three tiers: page routes that define Tauri webview entry points, workbench components that compose the VSCode-compatible editor layout, and utility functions that support the build and runtime process.

graph TB
    subgraph "Sky - UI Component Layer"
        Pages["Pages\nindex / Browser / Electron / Mountain / Isolation"]
        Workbenches["Workbench Components\nBrowser / Mountain / Default / NLS"]
        WorkbenchImpl["Workbench Implementations\nBrowserProxy/ · Electron/"]
        Functions["Function/\nDebug · Shared · Meta · Markup/Base"]
    end

    subgraph "Wind - Service Layer"
        Preload["Preload.js - Environment Shim"]
        WindServices["Effect-TS Services"]
        TauriIntegrations["Tauri IPC Integrations"]
    end

    subgraph "Mountain - Rust Backend"
        TauriEvents["Tauri Event System"]
        MountainCore["Mountain Core"]
    end

    Pages --> Workbenches
    Pages --> WorkbenchImpl
    Workbenches --> Preload
    WorkbenchImpl --> Preload
    Workbenches --> WindServices
    WorkbenchImpl --> WindServices
    WindServices --> TauriIntegrations
    TauriIntegrations --> TauriEvents
    TauriEvents --> MountainCore

Layer Responsibilities

• Pages - Astro route files that act as Tauri webview entry points. Each page reads environment variables to select and load the appropriate workbench variant.
• Workbenches - Composable layout components that assemble the VS Code-style editor shell. Variants exist for browser-only, Mountain-backed, Electron, and isolated modes.
• Functions - Build-time debug utilities, shared runtime helpers, HTML meta tag components, and base HTML layout skeleton components.

Key Modules

Sky Bridge

Source/Function/Sky/Bridge.ts subscribes to all sky:// Tauri events emitted by Mountain and routes them to VS Code workbench APIs or DOM manipulation. The bridge is modular: each Install* module in Bridge/ registers a related group of channels.

Mountain is used as a relay for Cocoon-to-Sky communication. Sky emits a sky:// Tauri event, Mountain re-emits it as a gRPC notification to Cocoon. This avoids a separate transport while keeping the workbench renderer and the extension host decoupled.

Bridge Modules

Build Optimization

Code Splitting (S1)

For non-bundled profiles (debug-electron, etc.) vs/** is entirely external, so Sky’s own module graph would otherwise concatenate into one large chunk. The manualChunks configuration in astro.config.ts splits it into four named chunks the browser preloader can fetch in parallel and V8 can parse on separate threads:

The bundled profiles (Pack=electron, etc.) must not use manualChunks because the workbench loader’s auto-split boundary (workbench.js to workbench.desktop.main.js) is required for correct initialization order.

Sourcemaps

Sourcemaps are generated as "inline" in dev builds (NODE_ENV=development) for WKWebView DevTools and profiler symbol resolution. Production builds disable sourcemaps to avoid shipping artifacts that are three times the bundle size.

Data Flow

The following sequence shows how a user action travels from the Sky UI through Wind services to the Mountain backend and back.

sequenceDiagram
    participant User as User Interaction
    participant Sky as Sky Component
    participant Wind as Wind Service
    participant Tauri as Tauri IPC
    participant Mountain as Mountain Backend

    User->>Sky: Click or Keystroke
    Sky->>Wind: Call service method (e.g. DialogService)
    Wind->>Tauri: tauri invoke command
    Tauri->>Mountain: Rust command handler
    Mountain->>Tauri: Return result
    Tauri->>Wind: Resolve Effect
    Wind->>Sky: Updated state
    Sky->>User: Re-render component

Startup Sequence

1. Tauri loads the webview pointing at Sky’s built output.
2. The page route reads environment variables and selects a workbench variant.
3. Wind’s Preload.ts shims window.vscode globals before VSCode code runs.
4. Wind bootstraps the Effect-TS service layer and establishes Tauri IPC.
5. Sky components subscribe to Wind services for live state updates.
6. Sky listens for Tauri events from Mountain (sky://terminal/data, sky://scm/update-group, sky://configuration/changed) to update UI.

Integration Points

Configuration

When no variant flag is set, index.astro loads Workbench/Default.astro. The recommended deployment always sets Mountain=true.

Astro configuration (astro.config.ts) resolves Wind and other @codeeditorland/* packages through Vite aliases, sets Source/ as the content root, and directs build output to Target/.

Related Documentation

• Sky overview
• Wind Deep Dive
• Mountain Deep Dive
• Output pipeline