Packages

Lima’s normative specifications are written to be implementation-language-agnostic: the goal is that a second, independent implementation can follow the spec directly, without reading the first one’s source. TypeScript is the reference implementation today. A Rust implementation is planned and, once started, will be checked against the same conformance corpus rather than treated as a from-scratch port with its own interpretation of edge cases.

Status

• Lima Core 1.0 specification — final
• Lima References 1.0 specification — final
• Conformance corpus — 250 cases, both specs, pinned by test
• TypeScript/JavaScript implementation — published as @limaformat/lima
• Rust implementation — not started; name reserved as a placeholder on crates.io

Both specifications are frozen at 1.0. Further changes will only ship as errata or a 1.0.1 revision, and only on the basis of the conformance corpus — not on a single implementation’s convenience.

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. A Rust implementation must reproduce those thresholds exactly (using Ryu or Dragonbox internally is fine; the digit sequence and fixed/exponential boundary must match). This is the one place the spec is ECMAScript-anchored; everything else is language-neutral by construction.

Installing

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

import { parse } from '@limaformat/lima'

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