DEV Community: Mr Smithnen

YINI Config Format reaches RC 6 - clearer strings, stricter parsing, and growing tooling ecosystem

Mr Smithnen — Fri, 19 Jun 2026 21:14:38 +0000

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-test test 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.

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.

YINI parser for Python is now released ✨️

Mr Smithnen — Sat, 13 Jun 2026 19:43:28 +0000

yini-parser-python is now public - feedback and early testing welcome

I recently made yini-parser-python public.

It is a Python parser for YINI - an INI-inspired, indentation-insensitive configuration format with explicit nested sections and predictable parsing rules.

The package is also on PyPI: pypi.org/project/yini-parser

YINI is still a young project and the spec is moving toward its first stable 1.0.0 release. That is exactly why I want feedback now - before things solidify. If something looks unclear, surprising, fragile, or difficult to maintain, I would rather hear about it at this stage than after the format is locked.

What the parser does

The goal of yini-parser-python is to provide a usable Python implementation of YINI. A small example looks like this:

@yini

^ Application
name = 'Demo Application'
version = '1.0.0'
debug = yes

^^ Server
host = 'localhost'
port = 8080

^^^ Logging
level = 'info'
file = './app.log'

Which represents this structure:

Application
└─ Server
   └─ Logging

Section nesting is defined by the markers - not by indentation or whitespace. That is the core idea.

Current status

The parser is early-stage but usable enough for testing and review. It currently passes the full yini-test suite - a separate Python-based test project with golden tests for parser behavior.

That suite has around 150 tests at the moment (76 lenient + 75 strict = 151 golden tests, I might make a more specific post about yini-test later on). It covers the important cases but is not yet comprehensive. More tests will be added as both the format and the implementations mature. The yini-test project is also planned to go public, if it has not already by the time you read this.

What kind of feedback would be useful?

Primarily:

Parser bugs
Unclear or surprising behavior
Edge cases worth adding to the test suite
Packaging or installation issues
Python API design
Documentation improvements
Places where the implementation could be simpler or more maintainable

Bug reports, small reproductions, pull requests, and implementation suggestions are all welcome. Alpha or beta testers too - even a quick "I tried this and it worked / did not work" is useful right now.

Why share it before 1.0.0?

Because this is when careful review matters most. Once a configuration format stabilizes, small syntax and behavior decisions become much harder to change. I would rather get practical feedback early - especially from developers with experience in configuration formats, parsers, tooling, or Python packaging.

YINI is not trying to replace JSON, YAML, TOML, or INI. Those all have valid use cases. This is a more focused experiment:

What if INI-style configuration had clearer nested structure, while staying readable and predictable?

That is the design space I am trying to test.

Links

If you try the parser and notice anything odd, unclear, or broken - feel free to make an issue, comment, or pull request, that would be very much appreciated.

Thanks for reading,

Marko

YINI (config format) RC.5 and yini-parser 1.5.0: making configuration stricter, clearer, and easier to trust

Mr Smithnen — Thu, 09 Apr 2026 21:48:41 +0000

YINI RC.5 and yini-parser 1.5.0: making configuration stricter, clearer, and easier to trust

I have been working for quite a while on YINI, a configuration format that tries to sit somewhere between INI, JSON, and YAML.

The original idea was simple: I wanted something that stayed pleasant to read and edit by hand, but was still structured enough to handle real-world configuration without feeling vague or fragile.

Over time, that idea turned into a full specification, parser work, CLI tooling, examples, grammar files, and a growing list of design decisions that needed to become clearer and more consistent.

This month was one of those milestones where several pieces moved forward together:

the YINI Specification reached v1.0.0-RC.5
the official Node.js / TypeScript parser reached v1.5.0

A lot of this update was not about flashy new syntax.

It was about making the format more precise, the parser more consistent, and strict mode more trustworthy.

TL;DR

YINI Spec reached v1.0.0-RC.5
yini-parser reached v1.5.0
strict mode now requires /END
strict mode now requires exactly one explicit top-level section
parser, grammar, examples, and tests were all brought into closer alignment

What YINI aims to be

YINI is a human-readable configuration format with:

explicit sections and nested sections
comments
strings, numbers, booleans, null, lists, and inline objects
predictable parsing rules
optional lenient and strict modes

A very small example looks like this:

^ App
name = "My App"
debug = false

    ^^ Features
    caching = on
    telemetry = off

The idea is to keep structure visible, without relying on indentation as syntax.

What changed in RC.5

The specification changes in YINI v1.0.0-RC.5 were mostly about tightening rules and reducing ambiguity.

1. `/END` is now required in strict mode

This is probably the biggest change.

The document terminator /END is now:

required in strict mode
optional in lenient mode

That may sound like a small detail, but it changes the contract of strict mode in an important way.

Before, a strict document could simply end at EOF.
Now, in strict mode, the document must explicitly declare that it is complete.

That helps in situations where configuration is:

copied only partly
truncated
transferred incompletely
cut off during file copy
broken during manual copy-and-paste

In other words, strict mode now becomes better at rejecting incomplete documents instead of quietly assuming they ended correctly.

A strict document now looks like this:

^ App
name = "My App"
debug = false
/END

That explicit ending felt like the right fit for a mode whose purpose is stricter validation.

2. Strict mode now clearly requires exactly one top-level section

Another important clarification was around top-level structure.

In lenient mode, orphan members can still exist at the root level, or be exposed under an implicit base, depending on implementation choices.

In strict mode, that is no longer just a loose expectation. The rule is now much clearer:

there must be exactly one explicit top-level section
top-level orphan members are not allowed
additional sections must be nested under that single root section

This makes strict mode easier to reason about and easier to validate.

3. Section header spacing rules were clarified

YINI section headers support both repeated markers and numeric shorthand.

Examples:

^ App
^^ Features
^7 DeepSection

RC.5 clarifies that:

repeated/basic section headers do not require a space before the name
numeric shorthand headers do require a space after the number

^App
^^Features
^7 DeepSection

But shorthand like this is not:

^7DeepSection

This was partly about grammar clarity, and partly about parser consistency.

4. Colon-based lists were fully removed from samples and examples

Colon-based lists had already been dropped earlier as a supported feature, but RC.5 cleaned this up fully across samples and examples.

So now the examples consistently use bracketed lists:

items = ["a", "b", "c"]

instead of older colon-list forms.

This is one of those changes that makes the format feel a bit less over-engineered and more coherent: less syntax surface, fewer edge cases, and less mental overhead.
Less syntax surface, fewer edge cases, less mental overhead.

5. The ANTLR4 grammar files were cleaned up

This was a quieter update, but a satisfying one.

The lexer and parser .g4 files were cleaned up and reorganized to make them:

easier to read
easier to maintain
more internally consistent
easier to keep aligned with the specification

That kind of work is not always visible from the outside, but it matters when the format is meant to have a real grammar rather than just an informal idea of how parsing should work.

What changed in yini-parser 1.5.0

On the implementation side, yini-parser v1.5.0 brings the Node.js / TypeScript parser in line with the RC.5 specification.

Strict mode behavior now matches the spec more closely

The parser now enforces that strict mode:

requires /END
requires exactly one explicit top-level section
applies the clarified section-header spacing rules
performs stricter checks around top-level structure

That means the behavior is now more predictable, and closer to what the specification actually says.

Lenient mode handling was refined

The parser also got better around the softer side of the format:

members outside explicit sections are handled more clearly in lenient mode
empty values and explicit null handling were clarified and tightened
top-level structural behavior is now easier to reason about in both modes

This matters because lenient mode is supposed to be forgiving, but still consistent.

Error handling and `throwOnError` were improved

A smaller but useful implementation fix was around error handling:

throwOnError option detection was fixed
public parameter names and related documentation were cleaned up
throwOnError now works more consistently together with the selected fail level

These are the kinds of details that make parser APIs much less frustrating to use in real tooling.

Validation and test coverage expanded

This release also expanded validation and tests around:

section headers
shorthand markers
backticked names
invalid dotted section names
error recovery
null handling
fixture parsing
smoke and integration coverage

A new large smoke/golden fixture was also added and validated:

c-industrial-monitoring-and-automation-platform.smoke.yini

And some previously skipped smoke tests were fixed and re-enabled as well.

That part makes me especially happy, because parser work is only as trustworthy as the tests around it.

Why these changes matter

None of this is about making YINI more complicated for the sake of it.

It is more about giving each mode a clearer purpose.

Lenient mode should remain practical for human-edited configuration.

Strict mode should be something you can trust in:

validation-heavy environments
CI
generated configuration
tooling
cases where incomplete or malformed input should fail fast

Requiring /END in strict mode, requiring exactly one top-level section, and tightening the parser around these rules all move in that direction.

Example: why strict `/END` helps

A document that just stops at EOF can look complete even when it is not.

A document that ends with /END is making a stronger statement:

this is the intended end of the document

That becomes useful when files are:

partially copied
manually pasted
embedded into another system
transferred incompletely
edited in the wrong place and saved in broken form

That is one of the main reasons I ended up feeling that strict mode should require it.

Example

// Lenient mode may allow:

name = "My App"

^ App
debug = true

// Strict mode requires:

^ App
name = "My App"
debug = true

/END

Current direction

YINI is getting close to the point where the core shape of the format feels stable.

There is still work to do, of course, but RC.5 and parser 1.5.0 feel like an important step because they strengthen the relationship between:

the specification
the grammar
the parser behavior
the examples
the tests

That kind of alignment is not glamorous, but it is the kind of thing that makes a format feel real.

If this kind of thing interests you

If you work with:

configuration-heavy tools
parser development
DSLs
TypeScript tooling
or just enjoy format design

I would genuinely be interested in how others think about strict vs lenient parsing, explicit document termination, and where a config format should draw the line between convenience and validation.

Links

Thanks for reading.

YINI CLI 1.2.1-beta: Safer Validation, Improved Help, and Smarter Output Handling

Mr Smithnen — Mon, 23 Feb 2026 19:00:31 +0000

This release improves validation robustness in yini-cli and makes CLI behavior more predictable and consistent.

1.2.1-beta — 2026-02

Improved

validate command:
- Strengthened diagnostics handling and metadata safety checks.
- Replaced unsafe internal assertions with controlled error handling.
- Improved --silent behavior and exit code consistency.

1.2.0-beta — 2026-02

Improved

--help now displays full help for all commands. Command-specific help remains available via:

  yini help <command>

Changed

Extended environment information is now available via the info command. The global --info option has been removed. Use:

  yini info

parse now defaults to formatted JSON output.
--compact outputs minified JSON (no whitespace).
Improved --output file handling:
- Output is written only if the destination file does not exist or is older than the source .yini file.
- --overwrite always replaces existing files.
- --no-overwrite prevents replacing existing files.

Added

--js option for parse to output JavaScript-style objects.

Deprecated

--pretty flag for parse (use --json explicitly if needed).

Try YINI CLI

Install globally:

npm install -g yini-cli

Or run without installing:

npx yini-cli --help

Explore the Project

GitHub: https://github.com/YINI-lang/yini-cli
npm: https://www.npmjs.com/package/yini-cli
Documentation & format specification: YINI homepage

I spent a week working on regression tests & metadata guarantees on the YINI config/settings parser

Mr Smithnen — Wed, 31 Dec 2025 01:09:58 +0000

Hey 👋

I just wanted to share a small win from my side project.

I've been working on something called YINI for a while now - it's a configuration format together with a TypeScript parser (with spec, grammar, etc).
The goal is basically to be a calmer middle ground between INI, JSON, and YAML for larger, real-world configuration files.

This past week I didn't really add any new features.
Instead, I finally sat down and did something I've been postponing for a long time: making the parser really solid.

I just shipped v1.3.3-beta, and most of the work went into building proper smoke and regression tests around the parser.
Not glamorous work at all - but it feels incredibly good now that it's in place.

The new tests parse a couple of large production-style configurations (one corporate SaaS setup and one more high-security / distributed setup) and verify that:

the output is identical in default mode, strict mode, and strict+metadata mode

metadata and diagnostics behave correctly for both valid and broken inputs

The API didn't change at all in this release - it's simply about making the project more predictable, safer to depend on, and easier to evolve.

It took longer than I expected, but I'm genuinely happy with where it landed.

This release was also important to get out because I'm using this parser as the foundation for the next big step of the project: expanding and refactoring the YINI CLI to make it more robust and production-ready.

If you're building developer tools, working with config-heavy systems, or just dealing with a lot of INI/JSON/XML files in general, you might find YINI interesting:

https://github.com/YINI-lang/yini-parser-typescript

I'd really appreciate any real-world testing or feedback. And good luck with your own side projects, they always end up being a lot more work than they first appear.

Thanks for reading.

YINI Homepage

🔧 yini-cli v1.1.1-beta released

Mr Smithnen — Sat, 20 Dec 2025 22:52:18 +0000

A new beta release of yini-cli, the command-line tool for working with YINI configuration files, is now available.

What's new in v1.1.1-beta

Updated: The CLI now uses YINI Parser v1.3.2-beta (previously v1.3.0-beta).

This brings in:

UTF-8 BOM handling (with and without BOM).
Shebang (#!) support (the line will be skipped if detected, without breaking parsing).
Additional parser robustness and test coverage.

About YINI

YINI is an INI-inspired configuration format designed for clarity and predictable behavior.
It supports nesting, comments, and a formally defined syntax, while remaining easy to read and edit by hand.

YINI Config Parser v1.3.2-beta Released (Node.js)

Mr Smithnen — Tue, 16 Dec 2025 20:46:37 +0000

A new beta of the official TypeScript parser for YINI is out!
This release focuses on real-world usability, robust file handling, and dependency hygiene.

If you're new to YINI: it's a modern, human-friendly configuration format that aims to keep INI-style readability while supporting real structure.

What's new in 1.3.2-beta

UTF-8 BOM support

YINI now correctly handles UTF-8 files with or without a Byte Order Mark (BOM).

Safe stripping of a leading BOM (U+FEFF)
Identical parsing behavior for:
- UTF-8 without BOM
- UTF-8 with BOM
- BOM followed by a blank line
Explicitly does not treat mid-file U+FEFF as a BOM
Comprehensive test fixtures added for all cases

This makes YINI more robust when consuming files created by different editors, platforms, and tooling.

Shebang (#!) support

YINI files can now start with a shebang line, which is ignored by the parser.

Dependency updates & security hygiene

All project dependencies (~14) updated to their latest versions
Includes TypeScript and packages with reported security advisories
Node.js type definitions intentionally left unchanged

No breaking API changes were introduced.

📦 Installation

npm install yini-parser

Or, if you're already using it, just bump to 1.3.2-beta.

Feedback welcome

YINI is still evolving, and feedback from real users is invaluable.
If you try this release and run into anything odd, or have thoughts on the format itself, feel free to open an issue or start a discussion.

Thanks to everyone following and testing the project 🙌
Thanks to everyone following and testing the project 🙌

The New YINI Homepage Is Live — A Modern, Human-Friendly Config Format

Mr Smithnen — Sun, 09 Nov 2025 02:20:41 +0000

Hey everyone 👋

I'm excited to share that the new homepage for YINI config format↗ is now live!

YINI is a modern, structured, human-friendly configuration format that tries to bring together the simplicity of INI with the flexibility of YAML.

🧩 What Is YINI?

YINI was designed to make configuration files both readable for humans and consistent for machines.

It takes inspiration from INI, YAML, and JSON — but simplifies the rules while still supporting modern features like:

Nested sections using clear markers (^, ^^, etc.)
Arrays [1, 2, 3] and objects { key: "value" }
Inline and full-line comments
Strict and lenient parsing modes

^ App
name = "Demo"
features = ["search", "dark-mode"]

^^ Server
host = "0.0.0.0"
port = 8080

🌐 The New Homepage

The new site — yini-lang.org ↗ — brings everything together:

🧭 Get Started guide
⚙️ Quick Tutorial with examples
📘 Full Specification
💡 FAQ and explanations

It's built with Astro + Tailwind, and designed to be fast, clean, and accessible — the perfect home for YINI as the ecosystem continues to grow.

📦 The YINI Ecosystem

yini-parser-typescript — the official TypeScript parser library
yini-cli — a simple CLI for parsing, validating, and converting YINI files
Specification — now at v1.0 RC stage, aligning parser behavior with the spec

Both projects are open-source on GitHub under @YINI-lang ↗

🗣️ Feedback Welcome

This is still early days for YINI, and community feedback is incredibly valuable.
If you’d like to try it out, explore the homepage, or contribute ideas, you’re more than welcome!
👉 YINI Homepage
👉 Check the parser on GitHub → yini-parser-typescript

Thanks for reading — and for helping shape a cleaner, more predictable future for config files 💡

— Marko Seppänen

🚀 YINI Parser v1.3.0-beta – Smarter Options, Safer Metadata, and New Controls

Mr Smithnen — Tue, 23 Sep 2025 14:20:52 +0000

I've just released yini-parser v1.3.0-beta 🎉 (Node package) - a big step forward for ergonomics, diagnostics, and developer experience when working with YINI configuration format, the human-friendly configuration format inspired by INI but with modern clarity.

This release focuses on cleaner public APIs, new output controls, and better tooling around metadata and CI.

✨ What's New

🐛 Fixed

Fixed a bug where buildResultMetadata(..) could occasionally produce an undefined error.

🔄 Renamed (Breaking API Changes)

To make public types more ergonomic for end-users, several interfaces were renamed:

AllUserOptions → ParseOptions
PrimaryUserParams → BasicOptions
OnDuplicateKey → DuplicateKeyPolicy

This makes names shorter, more consistent, and closer to their intent.

📖 Clarified

The strictMode parameter in TSDoc has been clarified: It defines the baseline ruleset (true = strict, false = lenient). Rule-specific options (e.g., treatEmptyValueAsNull, onDuplicateKey) may override the baseline. When overrides are applied, the effective mode becomes custom.

🆕 New Features

DocumentTerminatorRule and EmptyValueRule: new user-facing parsing rule value types.
quiet option:
- Only prints errors to the console.
- Warnings, notices, etc. are suppressed.
- Diagnostics are still captured in metadata.
silent option:
- Suppresses all console output, even errors.
- Programmatic callers should use metadata; CLI users should rely on the exit code.
throwOnError option:
- true (default): parser throws on parse errors.
- false: errors are reported via diagnostics without throwing.
- ⚠️ Planned change: next release will switch the default to false.
- ✅ Action: set throwOnError: true to keep current behavior, or throwOnError: false to adopt the upcoming behavior.

📊 Metadata Improvements

Added effectiveMode inside meta.diagnostics.effectiveOptions.
Metadata bumped to v1.1.1.
Fields strictMode and effectiveOptions now correctly reflect when rules override the initial mode.

The resultet metadata looks like this:

    "meta": {
        "parserVersion": "1.3.0-beta",
        "mode": "strict",
        "totalErrors": 0,
        "totalWarnings": 1,
        "totalMessages": 1,
        "runStartedAt": "2025-09-23T14:23:22.587Z",
        "runFinishedAt": "2025-09-23T14:23:22.618Z",
        "durationMs": 30.746,
        "preservesOrder": true,
        "orderGuarantee": "implementation-defined",
        "source": {
            "sourceType": "inline",
            "hasDocumentTerminator": false,
            "hasYiniMarker": false,
            "lineCount": 10,
            "byteSize": null,
            "sha256": "d79db628387ad8244fc3d394916e20b12c7fe6ef9c39fbf525b9579cdc95130a"
        },
        "structure": {
            "maxDepth": 5,
            "sectionCount": 5,
            "memberCount": 3,
            "keysParsedCount": null,
            "sectionNamePaths": [
                "User2",
                "User2.PrefsOfUser2",
                "User2.PrefsOfUser2.DeepSection",
                "User2.PrefsOfUser2.DeepSection.DeeperSection",
                "User2.PrefsOfUser2.DeepSection.DeeperSection.YetDeeperSection"
            ]
        },
        "metaSchemaVersion": "1.1.1"
    }

🛠️ CI & Tooling

The repo now runs stronger checks on every PR & release:

Security: CodeQL, npm audit, lockfile-lint, Gitleaks (SARIF), Semgrep (SARIF).
Grammar drift check: Ensures ANTLR-generated sources are committed.
Regression tests: Node/OS matrix coverage.
Releases: npm publish with provenance (tag-driven).

💬 Other

Parser summary logic and messages have been updated for clearer output.

📦 Install / Upgrade

npm install yini-parser@1.3.0-beta

npm update yini-parser

📚 Links

💡 This release lays groundwork for safer defaults and better developer ergonomics.

Thanks for reading!

🎉 YINI Parser v1.2.0-beta Released

Mr Smithnen — Sat, 13 Sep 2025 22:36:32 +0000

Hi folks!

I just published YINI Parser v1.2.0-beta 🎊 — the latest beta release of the TypeScript/Node.js parser for the YINI configuration format.

This release comes with a mix of fixes, refactors, and quality-of-life improvements, especially around runtime safety and metadata handling.

✨ What's New

🛠️ Fixes

parseFile() now correctly passes through all options (e.g. includeDiagnostics), so behavior now matches parse(..).
Fixed a small typo (in in) in file parsing error messages.

📊 Metadata Improvements

The result metadata structure has been bumped to version 1.1.0.

preservesOrder: true // Member/section order is implementation-defined, not mandated by the spec.
orderGuarantee: 'implementation-defined'
orderNotes?: string

These fields make it easier for tooling to reason about how order is preserved.

🔒 Safer Runtime

The public YINI class was refactored to use per-invocation runtime state.
This prevents race conditions when multiple parse(..) / parseFile(..) calls run in parallel.

🗂️ File Layout & Naming

To keep things consistent and tidy:

src/parseEntry.ts → src/pipeline.ts (and _parseEntry(..) → runPipeline(..)).
core/types.ts → core/internalTypes.ts.
Public-facing types/interfaces moved to src/types/index.ts.
src/yiniHelpers.ts → src/utils/yiniHelpers.ts.

🧹 Naming Consistency

Renamed includeMetaData → includeMetadata.
Replaced old TJSObject type with the clearer ParsedObject type throughout the codebase.

📚 Documentation & Tests

Expanded and improved TSDoc comments across the public API.
Unit tests are now colocated with source files (src/**), ensuring 1:1 visibility between code and its tests. This reduces the chance of missing coverage when refactoring.

🚀 Why This Matters

This release is all about stability and clarity:

You get more accurate metadata out of the box.
Safer runtime behavior when parsing concurrently.
Cleaner project layout that makes contributing and navigating the repo easier.
Better docs for anyone building on top of YINI Parser.

Code Example:

import { ParsedObject, YiniParseResult } from '../types'
import YINI from '../YINI'

const result: YiniParseResult = YINI.parseFile(
    'myConfigFile.yini',
    { includeMetadata: true },
)

🔗 Links

📦 npm: yini-parser
💻 GitHub: YINI Parser
📖 YINI Homepage

🙏 Feedback

As always, feedback and contributions are super welcome! Try it out and let me know if you hit any edge cases.

YINI CLI v1.0.2-beta — Smarter Number Parsing 🚀

Mr Smithnen — Mon, 11 Aug 2025 17:26:43 +0000

Just rolled out YINI v1.0.2-beta, and this one focuses on making the parser more capable and rock-solid when it comes to handling numbers.

🔧 What's New

The internal YINI Parser has been upgraded to v1.0.2-beta, bringing full support for:

Negative values

Edge cases across all number types:

- Integers
- Floats
- Hexadecimal
- Binary
- Octal
- Duodecimal (base-12)
- Exponential notation

💡 Why It Matters

If you're working with configs that push the limits—maybe big integer IDs, scientific values, or alternative base notations—this update ensures they'll parse correctly, consistently, and without surprises.

Usage

Installation

Install it globally from npm

Open your terminal and run:
```
npm install -g yini-cli
```

Test functionality

Create a simple test file, for example: config.yini:

^ App
  name = 'My App Title'
  version = '1.2.3'
  pageSize = 25
  darkTheme = off

Then run:

yini parse config.yini

Expected result, your CLI should output a parsed version of the config and output something similar to:

{
    App: {
        name: 'My App Title',
        version: '1.2.3',
        pageSize: 25,
        darkTheme: false
    }
}

All Supported Number Format

In YINI config format below:

        @yini

        ^ App
          name = 'My App Title'
          version = "1.2.3"
          pageSize = 25
          darkTheme = off

        ^ NumberFormats

          ^^ HexFormat              // Hexadecimal (base-16)
             hex    = #FF0066       // Default notation
             altHex = 0xFF0066      // Alternative notation
          ^^ BinFormat              // Binary (base-2)
             bin    = %10101111     // Default notation
             altBin = 0b10101111    // Alternative notation
          ^^ OctFormat              // Octal (base-8)
             oct    = 0o755         // (decimal 493)
          ^^ DozFormat              // Duodecimal (base-12)
             doz    = 0z10XE        // Default notation:     X=10, E=11
             altDoz = 0z10AB        // Alternative notation: A=10, B=11

Will produce following JS object:

{
  App: {
    name: 'My App Title',
    version: '1.2.3',
    pageSize: 25,
    darkTheme: false
  },
  NumberFormats: {
    HexFormat: { 
      hex: 16711782,
      altHex: 16711782
    },
    BinFormat: { 
      bin: 175, 
      altBin: 175
    },
    OctFormat: { 
      oct: 493 
    },
    DozFormat: { 
      doz: 1859, 
      altDoz: 1859
    }
  }
}

How to Use YINI Config Files in a Node.js App (with Real Examples)

Mr Smithnen — Sat, 02 Aug 2025 23:29:53 +0000

🙋‍♂️ Why I Wrote This

You know that moment when you're knee-deep in a side project and you just want a clean config file?

Something easier on the eyes than JSON, but more structured than old-school INI?

That was me — and that's how YINI started.

Not to reinvent configuration formats, but just to make one that I wouldn't dread editing.

In this post, I'll walk you through how to actually use YINI in a Node.js app, with real examples pulled straight from my own parser tests and tooling setup. It's simple, flexible, and (hopefully) a bit fun.

📦 Installing the Parser

First, install the YINI parser from npm:

npm install yini-parser

🧪 Parsing a Basic Config

Let's start with a simple YINI config:

^ App
title = 'My App Title'
items = 25
isDarkTheme = true

Here's how you load it in your app:

import YINI from 'yini-parser';

const config = YINI.parse(`
    ^ App
    title = 'My App Title'
    items = 25
    isDarkTheme = true
`);

console.log(config.App.title); // 'My App Title'

YINI requires strings to be quoted for clarity.
Numbers, booleans, and nulls are parsed correctly too — without weird surprises.

The above config corresponds to this JavaScript object:

{
  App: {
    title: 'My App Title',
    items: 25,
    isDarkTheme: true
  }
}

📂 Loading from a File

In most real projects, you'll want to load your config from a file.
yini-parser provides a helper for that: YINI.parseFile(..).

import YINI from 'yini-parser';

const config = YINI.parseFile('./config.yini');

console.log(config.App.title); // e.g., 'My App Title'

This works with .yini files, and supports options like strict mode or metadata.

Under the hood, parseFile(..) just reads the file and passes it to YINI.parse(..). Simple and clean.

💡 Structured Config with Nested Sections

Sometimes your config grows — and when it does, structure helps.
YINI supports nested sections (similar as to in Markdown) but with using caret-based indentation:

@yini

^ App
name = "Nested Example"
version = "1.0.0"
debug = OFF

    ^^ Database
    host = "db.example.com"
    port = 3306
    user = "appuser"
    password = "dbpassword"

        ^^^ Pool
        min = 2
        max = 10
        idleTimeout = 300

    ^^ Logging
    level = "info"
    logToFile = ON
    filePath = "./logs/app.log"

/END

You can parse this in strict mode like this:

const config = YINI.parse(yiniString, true); // true = strict mode

The resulting object:

{
  App: {
    name: 'Nested Example',
    version: '1.0.0',
    debug: false,
    Database: {
      host: 'db.example.com',
      port: 3306,
      user: 'appuser',
      password: 'dbpassword',
      Pool: { min: 2, max: 10, idleTimeout: 300 }
    },
    Logging: { level: 'info', logToFile: true, filePath: './logs/app.log' }
  }
}

🛠 Optional Metadata

Want more than just key/values?
You can enable metadata mode to get some stats and some other info — useful for diagnostics, etc.

const configWithMeta = YINI.parse(yiniString, false, 'auto', true);

🗨️ Comments — Your Way

YINI supports a variety of comment styles:

// This is a comment
# So is this
-- And this

/*
Block comments
are supported too
*/

✅ Recap

YINI isn't trying to be better than JSON, TOML, or YAML.
It just tries to be clear, consistent, and pleasant to use — especially when you want nesting without indentation sensitivity, or strict validation without a mess of brackets.

If you like working with structured configs in Node.js and want something that's:

Human-friendly
Easy to read
Tooling-ready
Just structured enough…

🔗 Links

npm: yini-parser
GitHub: YINI-lang/yini-parser-typescript
YINI Homepage

– Marko
Creator of YINI

Note: This article was originally published on Medium.

DEV Community: Mr Smithnen

YINI Config Format reaches RC 6 - clearer strings, stricter parsing, and growing tooling ecosystem

YINI Specification RC 6 is now released

What changed in RC 6?

Clearer section markers

Strict and lenient mode behavior is more clearly defined

Comment syntax is more consistent

Hexadecimal numbers use clearer prefixes

String handling was simplified

String concatenation is stricter and more predictable

Inline objects are more clearly specified

Lists remain bracketed and explicit

Duplicate keys and sections are safer

Strict files can use a .strict.yini suffix

The YINI ecosystem is growing too

Why RC 6 matters

Try it

Links

Feedback welcome

YINI parser for Python is now released ✨️

yini-parser-python is now public - feedback and early testing welcome

What the parser does

Current status

What kind of feedback would be useful?

Why share it before 1.0.0?

Links

YINI (config format) RC.5 and yini-parser 1.5.0: making configuration stricter, clearer, and easier to trust

YINI RC.5 and yini-parser 1.5.0: making configuration stricter, clearer, and easier to trust

What YINI aims to be

What changed in RC.5

1. /END is now required in strict mode

2. Strict mode now clearly requires exactly one top-level section

3. Section header spacing rules were clarified

4. Colon-based lists were fully removed from samples and examples

5. The ANTLR4 grammar files were cleaned up

What changed in yini-parser 1.5.0

Strict mode behavior now matches the spec more closely

Lenient mode handling was refined

Error handling and throwOnError were improved

Validation and test coverage expanded

Why these changes matter

Example: why strict /END helps

Example

Current direction

If this kind of thing interests you

Links

YINI CLI 1.2.1-beta: Safer Validation, Improved Help, and Smarter Output Handling

1.2.1-beta — 2026-02

Improved

1.2.0-beta — 2026-02

Improved

Changed

Added

Deprecated

Try YINI CLI

Explore the Project

I spent a week working on regression tests & metadata guarantees on the YINI config/settings parser

🔧 yini-cli v1.1.1-beta released

What's new in v1.1.1-beta

About YINI

Links

YINI Config Parser v1.3.2-beta Released (Node.js)

What's new in 1.3.2-beta

UTF-8 BOM support

Shebang (#!) support

Dependency updates & security hygiene

📦 Installation

Links

Feedback welcome

The New YINI Homepage Is Live — A Modern, Human-Friendly Config Format

🧩 What Is YINI?

🌐 The New Homepage

📦 The YINI Ecosystem

🗣️ Feedback Welcome

🚀 YINI Parser v1.3.0-beta – Smarter Options, Safer Metadata, and New Controls

✨ What's New

🐛 Fixed

🔄 Renamed (Breaking API Changes)

📖 Clarified

🆕 New Features

Strict files can use a `.strict.yini` suffix

1. `/END` is now required in strict mode

Error handling and `throwOnError` were improved

Example: why strict `/END` helps