Packages

Three published implementations of Lima Core 1.0 and References 2.0, verified against the same language-neutral conformance corpus.

Lima’s normative specifications are written to be implementation-language-agnostic: an independent implementation can follow the specs directly without reading another binding’s source. TypeScript is the reference implementation; Rust and Go independently implement the same Lima Core 1.0 and Lima References 2.0 semantics. All three are checked against the same language-neutral conformance corpus rather than carrying their own interpretations of edge cases.

Status

• Lima Core 1.0 specification — final
• Lima References 2.0 specification — final
• Conformance corpus — 211 Core 1.0 cases (a byte-frozen 149-case 1.0.0 baseline plus additive errata through 1.0.9) and a separate 136-case References 2.0 suite
• TypeScript/JavaScript implementation — published as @limaformat/lima 0.5.0; passes Core 1.0 and References 2.0 (136/136) through the public API
• Rust implementation — published as lima 0.5.0; passes both suites and exposes References 2.0 through parse
• Go implementation — published as github.com/limaformat/lima/go at go/v0.5.0; passes both suites and exposes References 2.0 through Parse

Lima Core 1.0 is frozen. Corrections ship only as additive errata revisions (Core is currently at 1.0.9), driven by the conformance corpus rather than a single implementation’s convenience, and never altering the byte-frozen 1.0.0 baseline. Lima References 2.0 is final as of 2026-08-12.

An earlier References 1.0 was published briefly in mid-2026 and superseded almost immediately by References 2.0, which is not syntax-compatible with it. Its archived specification and 101-case regression corpus stay in the repository; it is not a current target.

Why TypeScript first

Lima’s own tooling — the site generator this documentation is built with, and the broader author ecosystem it grew out of — is Bun/TypeScript-native, so the reference implementation started there. That’s a starting point, not a ceiling: the specs don’t privilege JavaScript semantics anywhere except one explicitly documented, narrow exception.

Float serialisation (References §3.5.1) is normatively anchored to the ECMAScript Number::toString algorithm, including its fixed-vs-exponential thresholds — a deliberate trade-off for cross-language output parity. Any other implementation must reproduce those thresholds exactly (using Ryu or Dragonbox internally is fine; the digit sequence and fixed/exponential boundary must match) — both the Rust and Go implementations do. This is the one place the spec is ECMAScript-anchored; everything else is language-neutral by construction.

Installing

TypeScript/JavaScript — References 2.0:

npm install @limaformat/lima
bun add @limaformat/lima

import { parse } from '@limaformat/lima'

const result = parse(input, { partials: { author: 'Ada' } })
// ${key} document references, $(key) partial references

Rust — References 2.0:

cargo add lima@0.5.0

use lima::{parse, ParseOptions};

let result = parse(input, ParseOptions::default())?;
// ${key} document references, $(key) partial references

Go — References 2.0:

go get github.com/limaformat/lima/go@v0.5.0

import lima "github.com/limaformat/lima/go"

value, err := lima.Parse(input, lima.ParseOptions{})
// ${key} document references, $(key) partial references

See the Guide for the full TypeScript API, and Migrating from YAML if you’re moving existing frontmatter over.

Editor support

A VS Code extension — limaformat.vscode-lima — adds syntax highlighting for .lima files and Markdown/MDX frontmatter, plus live diagnostics run through the bundled TypeScript parser. Published on the VS Code Marketplace and on Open VSX for VSCodium, Cursor, and other compatible editors.