Sindre Sorhus releases SOML, a config format that pins types to syntax

A new configuration language from a prolific maintainer

Sindre Sorhus has released SOML, a configuration file format whose name expands, tongue in cheek, to "Sindre's Objectively Marvelous Language." The project's repository surfaced on the Hacker News front page on November 2, 2026, and opens with a warning that the specification is a draft and that feedback is welcome.

According to the README, SOML keeps JSON's underlying model — a tree of objects and arrays — along with its strictness, while stripping the punctuation overhead and adding things JSON has never offered: comments, literal strings, block strings, dates, instants, and durations.

One rule: syntax, not content

The format rests on a single principle: how a value is written determines its type, and nothing is ever retyped by inspecting its contents. 123 is an integer; '123' is a string. Strings always carry quotes, so a bare word that resembles a boolean or number is simply a parse error — country: no is rejected rather than becoming false, the notorious YAML trap.

The ergonomic pitch is straightforward. The top level of a file needs no braces, keys need no quotes (dashes are allowed), and line breaks replace commas. Comments — both # lines and /* */ blocks — may appear anywhere whitespace is permitted. Single-quoted strings are literal, so Windows paths and regular expressions need no escaping; double quotes provide escape sequences. Multi-line prose goes in block strings that are dedented relative to the closing delimiter's column.

Dates such as 2026-09-19, instants such as 2026-09-19T14:00:00Z, and durations such as 1h30m are first-class values, so a reader never has to wonder what unit timeout: 30 carries. Integers are exact to 64 bits and stay a distinct type from floats — the spec deliberately keeps 3 and 3.0 different — and the format adds underscore separators, binary, octal, and hex literals, plus infinity.

Structurally, braces and line breaks carry the meaning, so indentation is purely cosmetic. Tabs, spaces, and copy-paste cannot silently reshape a document the way they can in YAML, except inside block strings where indentation is text.

Where it aims to hurt less than the incumbents

In the README's framing, JSON is rigorous but noisy — braces, quotes, and commas everywhere, with no comments — while YAML is easy on the hands but hard on the mind. The document lists concrete failures in widely used YAML parsers: PyYAML, following YAML 1.1, turns no into false, reads 01234 as the octal value 668, and interprets 22:22 as a base-60 number; even YAML 1.2 treats version: 3.10 as the float 3.1; js-yaml collapses the large integer 9007199254740993 into 9007199254740992; PyYAML silently keeps the last of duplicate keys; and YAML's default block scalars append a trailing newline that SOML's block strings omit.

SOML responds by making duplicate keys, lone surrogates, and out-of-range numbers hard errors, and by requiring all keys to be strings — 404: is the key '404', never an integer or boolean.

A spec designed for agreement between implementations

Two further commitments stand out. First, a canonical form: equal values must encode to equal bytes, which makes files suitable for hashing, signing, and comparison. A separate formatter, whose rules are part of the specification, preserves comments, member order, and the spelling of each value, and defined editing rules let a tool rewrite one value without disturbing the rest of a document. Second, the grammar parses in a single pass with no lookahead, and every implementation must run a shared, language-neutral conformance suite of nearly 1,000 cases — an explicit attempt to prevent the parser-to-parser divergence that has fragmented YAML.

Why it matters

Configuration formats are long-lived infrastructure; a choice made in an afternoon can burden a project for a decade. SOML's real wager is not syntax but interoperability: a canonical encoding, a specified formatter, and a conformance suite target exactly the fragmentation — YAML 1.1 versus 1.2, one parser's quirk against another's — that made the incumbents exhausting. Sorhus is among the most prolific maintainers in open-source JavaScript, and his utilities sit inside a vast number of npm projects, giving SOML a distribution channel most format proposals never get. Working against it: the spec is explicitly a draft, tooling beyond the repository itself is unproven, and displacing JSON and YAML demands editor support, schema ecosystems, and years of buy-in. The conformance suite is the detail to watch — if other implementations adopt it faithfully, SOML could become a credible default for human-written config; without that, it risks remaining a pleasant dialect.