YINI Specification RC 6 is now released
The YINI configuration format has reached Specification Release Candidate 6.
YINI is a configuration format designed to feel familiar if you like INI-style files, but designed to bring more explicit structure, clarity, useful data types, and predictable parsing rules to real-world configuration needs..
The short version:
@yini
^ App
name = "Example"
version = "1.0.0"
debug = false
^^ Server
host = "127.0.0.1"
port = 8080
^^ Features
enabled = [
"auth",
"logging",
"metrics",
]
YINI tries to sit somewhere between classic INI, JSON, TOML, and YAML:
- More structured than traditional INI.
- Less punctuation-heavy than JSON.
- Indentation-insensitive unlike YAML.
- Explicit about parsing rules and validation behavior.
RC 6 is an important release because it tightens several parts of the language and moves the format closer to a stable 1.0 specification.
What changed in RC 6?
RC 6 includes a number of syntax and behavior updates. The main theme is the same as before:
Make the format clear for humans, but deterministic for parsers.
Here are some of the notable updates.
Clearer section markers
YINI uses section markers to define structure.
^ App
name = "MyApp"
^^ Server
host = "localhost"
^^^ TLS
enabled = true
The number of section markers defines the nesting level. This keeps hierarchy visible without relying on indentation.
The primary section marker is:
^
YINI also supports alternative section markers, but ^ remains the recommended default for most files and examples.
Strict and lenient mode behavior is more clearly defined
YINI has two parsing modes:
Lenient mode — practical, forgiving, and intended as the default.
Strict mode — validation-focused and intended for stricter tooling, CI checks, and production-sensitive configuration.
A file can declare its intended mode:
@yini strict
or:
@yini lenient
RC 6 clarifies how these declarations should behave when the file is parsed in a different mode.
The goal is to avoid silent surprises. If a file says it expects strict behavior, tools should not quietly treat that as “close enough” in a looser context.
Comment syntax is more consistent
YINI supports common comment styles:
# A line comment
// Another line comment
; A full-line comment
/*
A block comment.
*/
RC 6 clarifies comment behavior, including that # is now consistently treated as a comment marker outside strings.
This also affects number syntax, because # is no longer used for hexadecimal numbers.
Hexadecimal numbers use clearer prefixes
Instead of using # for hexadecimal notation, YINI now uses clearer forms such as:
color = 0xffcc00
mask = hex:ffcc00
This avoids conflict with comment syntax and makes the language easier to scan.
Digit separators are also supported for readability:
maxSize = 1_000_000
flags = 0b1111_0000
id = 0x_ab_cd_12_34
String handling was simplified
RC 6 continues to refine string behavior.
YINI supports different string forms for different needs:
name = "Example"
path = R"C:\Users\marko\config"
message = C"Line one\nLine two"
The distinction between raw strings and classic escaped strings is important:
- Raw strings preserve backslashes.
- Classic strings interpret escape sequences.
Triple-quoted strings are also available for longer text.
description = """
This is a longer string.
It can span multiple lines.
"""
The goal is to make string behavior explicit instead of surprising.
String concatenation is stricter and more predictable
String concatenation uses +, but RC 6 makes the rules more explicit.
In strict mode, concatenation is intentionally conservative:
title = "YINI " + "Config"
All operands must be string literals.
In lenient mode, scalar values may be allowed after the first string literal:
message = "Port: " + 8080
Result:
Port: 8080
But this is still string concatenation only. It is not arithmetic.
value = 1 + 2
That should not be treated as numeric addition.
This is one of the places where YINI deliberately favors predictability over cleverness.
Inline objects are more clearly specified
YINI supports inline objects for compact structured values:
database = {
host: "localhost",
port: 5432,
ssl: true,
}
RC 6 clarifies the preferred object member syntax.
The canonical form is:
key: value
Lenient parsers may accept key = value in inline objects, but strict mode should require :.
That gives users a friendly mode while still keeping strict mode suitable for validation.
Lists remain bracketed and explicit
Lists use brackets:
plugins = [
"auth",
"cache",
"metrics",
]
Trailing commas are convenient in hand-edited files and may be accepted in lenient mode.
Strict mode can reject them if the specification requires stricter validation.
Missing entries are not silently treated as null. This is intentional. YINI should not guess structure that was not written.
Duplicate keys and sections are safer
RC 6 keeps duplicate handling conservative.
Duplicate keys in the same section and nesting level are not silently overwritten.
In lenient mode, the first definition wins and later duplicates should produce a warning.
In strict mode, duplicates are errors.
This avoids one of the most frustrating configuration-file problems: a value being accidentally overridden far below the original definition.
Duplicate sections are also not treated as implicit merges. YINI avoids hidden merge behavior because it can become hard to reason about in larger files.
Strict files can use a .strict.yini suffix
RC 6 also documents the recommended naming convention for strict-mode YINI files:
config.strict.yini
This is not meant to replace the actual parser mode, but it gives humans and tools a useful signal.
For example, a CI workflow or editor extension can warn if a file looks like it should be strict but is being parsed differently.
The YINI ecosystem is growing too
Alongside the specification, there are now several related tools and repositories around the format.
The main pieces include:
- The YINI specification.
- A TypeScript parser.
- A Python parser.
- A CLI tool for parsing and converting YINI.
- Syntax highlighting support for editors using TextMate-style grammars.
- A public
yini-testtest suite for parser behavior and compatibility checks. - The YINI homepage and documentation.
The yini-test repository is especially important because it gives parser implementations a shared set of cases to validate against. This helps keep behavior consistent across languages instead of each parser drifting in its own direction.
The CLI is useful for trying YINI quickly:
npx yini-cli parse config.yini
The TypeScript parser can be used directly in Node.js or TypeScript projects, and the Python parser is also being developed for Python-based tooling and applications.
Why RC 6 matters
RC 6 is not about adding flashy features.
It is mostly about tightening the language:
- Fewer ambiguous rules.
- Clearer strict vs lenient behavior.
- Safer duplicate handling.
- More explicit string behavior.
- Clearer number syntax.
- Better parser consistency.
- And stronger alignment between the specification and tooling.
That is the kind of work a configuration format needs before calling itself stable.
A config format should be boring in the right ways. It should be easy to read, hard to misread, and predictable for tools.
That is the direction YINI is aiming for.
Try it
A minimal YINI file looks like this:
@yini
^ App
name = "Hello YINI"
debug = false
^^ Server
host = "127.0.0.1"
port = 8080
Parse it with the CLI:
npx yini-cli parse config.yini
The result is structured data that can be exported as JSON or used by tools and applications.
Links
- YINI homepage:
- Specification:
- TypeScript parser:
Feedback welcome
RC 6 is a release-candidate specification, so feedback is still useful.
Especially helpful feedback includes:
- Confusing syntax rules.
- Parser edge cases.
- Unclear examples.
- Places where strict and lenient behavior should be clearer.
- Documentation gaps.
- And real-world configuration examples that would be useful to test against.
If you try YINI, find a rough edge, or have opinions about configuration formats, I would be happy to hear them.
SOCIAL SHARE CARD GENERATOR