SM StructuredMerge

Launch implementations

Four implementations, one contract.

StructuredMerge launches with Go, TypeScript, Rust, and Ruby implementations. They are peers: each consumes the same public spec and shared fixture corpus.

How to think about them

The language repos are not separate products. They are interchangeable implementation surfaces for teams working in different runtimes.

A ruleset, fixture, diagnostic shape, or review outcome should mean the same thing whether it is exercised through Go, TypeScript, Rust, or Ruby.

What launch means

The launch set demonstrates that StructuredMerge is not tied to one parser stack or one language ecosystem.

The shared spec and fixtures remain the source of truth. Implementations prove compatibility by running against that corpus.

Implementation repos

Choose the runtime that fits the host tool.

Go

For CLIs, services, and automation that need a compact native implementation.

structuredmerge-go

Rust

For embeddable systems, performance-sensitive tooling, and native integrations.

structuredmerge-rust

Ruby

For Ruby tooling and automation that should follow the same StructuredMerge contract.

structuredmerge-ruby

Compatibility model

  • Specs define the public contract.
  • Fixtures define expected behavior for document families and merge cases.
  • Implementation repos expose native packages for their ecosystems.
  • Conformance results show which families and cases are supported.
  • Differences belong in explicit capability reporting, not hidden behavior.

What comes next

As the fixture corpus grows, each implementation can add support slice by slice. New languages can join by consuming the same specs and fixtures instead of inventing their own behavior.

The goal is steady convergence: native packages in multiple runtimes, tested against the same public examples, with unresolved cases reported in a reviewable form.