Hone Documentation
Hone is a native, AI-powered code editor built in TypeScript and compiled to native binaries via the Perry compiler — a TypeScript-to-native AOT compiler written in Rust. Hone runs without V8 or Node.js at runtime; the generated binaries link directly against platform UI frameworks.
Who these docs are for
- Hone contributors — developers working on the IDE itself, its editor, services, or built-in extensions
- Plugin developers — anyone building V2 plugins for the Hone marketplace using
@hone/sdk
How to navigate
| Section | Audience | What you’ll find |
|---|---|---|
| Getting Started | Contributors | Build instructions, project layout, Perry constraint cheat sheet |
| Architecture | Contributors | Deep-dives into how each major subsystem works |
| Packages | Contributors | Reference docs for every package in the monorepo |
| Plugin Development | Plugin devs | Guides for building, testing, and publishing plugins |
| Perry Integration | Contributors | Detailed Perry AOT constraints, FFI conventions, and build commands |
| Services | Operators | How to run and deploy Hone’s backend services |
| Testing | Contributors | Per-package test runners and UI testing tools |
| Contributing | Contributors | Dev environment setup and project conventions |
Key concepts
- Perry AOT — TypeScript is compiled ahead-of-time to native machine code. There is no JavaScript runtime. This imposes specific constraints on the TypeScript you can write.
- Monorepo, no workspace manager — Each package (
hone-core,hone-editor,hone-ide, etc.) is independent with its ownpackage.json. There is no top-level package.json or Yarn/pnpm workspace. - TS-authoritative rendering — TypeScript owns all document state. Native platform code (Rust FFI) is a rendering cache that receives computed lines and viewport state.
- Two extension systems — V1 built-in extensions ship with the IDE. V2 plugins are independently compiled native binaries distributed via the marketplace.