Forem: Mr Smithnen

YINI CLI 1.2.1-beta: Safer Validation, Improved Help, nd 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.

YINI Parser Hits Beta - Human-Friendly, Modern Config Format with Minimal Syntax Noise

Mr Smithnen — Sun, 27 Jul 2025 18:49:02 +0000

🚀 YINI Parser 1.0.0 Beta 1 is out!

If you're tired of bloated, hard-to-read configuration formats. Or just looking for something truly human-friendly, simple section nesting, etc - Check out YINI: a modern, minimal configuration file format, now with a TypeScript parser for Node.js.

This beta release includes:

The parser is now in beta - moved from alpha status, reflecting increased stability and feature completeness.
Cleaned up exports to support importing this library in both CommonJS (CJS) and ECMAScript Modules (ESM) environments.
Implemented full support for parsing YINI lists, according to the latest specification.
Updated the grammar and parsing logic to match the latest YINI specification v1.0.0-RC.1.
An expanding set of real-world fixtures and tests.

Quick Start

A minimal example using YINI in TypeScript:

import YINI from 'yini-parser'

const config = YINI.parse(`
^ App
name     = 'My Title'    // App display name.
items    = 25
darkMode = true

    // Sub-section of App.
    ^^ Special
    primaryColor = #336699
    isCaching = false
`)

// To parse from a file instead:
// const config = YINI.parseFile('./config.yini')

console.log(config.App.name)                // My Title
console.log(config.App.Special.isCaching)   // false
console.log()
console.log(config)

Output:

My Title
false

{
  App: {
    name: 'My Title',
    items: 25,
    darkMode: true,
    Special: { 
      primaryColor: 3368601,
      isCaching: false
    }
  }
}

That's it!

And installation in Node.js is just:

npm install yini-parser

The library is out on npm here: YINI Parser on npm, so you can try it out for real :P

If you like what you reading, I want to get more into the YINI format: Here's intro to YINI Config Format.

Questions, feedback, or bugs? Open an issue on GitHub or drop a comment below!

Thanks for reading!

Marko Seppänen

YINI Homepage

Getting Started with YINI: A Modern, Human-Friendly Config Format

Mr Smithnen — Tue, 22 Jul 2025 22:46:13 +0000

Intro to YINI Config Format

Hi, first you might wonder what yini - a Japanese poem or? :P

Nah, no :) - YINI is a minimal and human-readable configuration file format (with a formally defined grammar and a specification).

Quick Start

^ App
name = "MyApp"
enabled = true

It was designed for clarity and simplicity, offering features that aims to improve on classic INI while avoiding the complexity of formats like YAML - yet being less noisy than JSON and TOML.

Here's an introduction to the YINI config format...

1. Sections

Group settings under a named header. A section header name starts with ^.

Start a section with ^, e.g.:

^ App
title = "AppName"

Alternative section markers to ^ are also supported: <, §, € (e.g. < Section).

2. Key = Value

Each line inside a section is a key (name) and value, separated by =.

Write settings as key = value:

maxConnections = 100
enableLogging  = true

3. Values

Values can be:

Strings (always quoted): "hello" or 'world' (either single or double quoted)
Numbers: 42, 3.14 or -10
Booleans: true, false, on, off, yes, no (all case-insensitive)
Nulls: Use null or leave the value blank after = (in lenient mode)
Lists:
- JSON‑style: ["red", "green", "blue"]
- Colon‑style:
```
fruits:
    "Pear",
    "Cherry",
    "Banana"
```

4. Comments

Various commenting styles are supported:

// This is a line comment
timeout = 30  // inline comment
# This is also a line comment (must have a space after #)
interval = 30  # inline comment (must have a space after #)
/* Block comment spanning
   multiple lines */
; Full line comment (must be whole line).

👆 Caveat: If you use # for comments, always put a space after the #.
(Otherwise, the parser might misinterpret it as part of a value.)

5. Nested Sections

Use extra carets ^ for sub‑sections:

^ Parent
^^ Child

// Add another caret `^` and you get a sub-section
// of the previous section, and so...
^^^ SubChild

If you prefer, you can indent the nested section for visibility:

^ Main
    ^^ Sub
    host = "db.example.com"

One can nest multiple sections:

^ Root
^^ Sub
^^^ SubSub
^ BackToRoot

Example with indented sections:

^ Root
value = 'At level 1'
    ^^ Sub
    value = 'At level 2'
        ^^^ SubSub
        value = 'At level 3'

^ BackToRoot
value = 'Back at level 1'

The above Yini code will produce the following JavaScript object:

// JS object
{
  Root: {
    value: 'At level 1',
    Sub: { value: 'At level 2', SubSub: { value: 'At level 3' } }
  },
  BackToRoot: { value: 'Back at level 1' }
}

See section 9 for more advanced marker and naming options.

6. Lists

👆 List support is planned for an upcoming release.

// JSON‑style list
colors = ["red", "green", "blue"]

// Colon‑style list
fruits:
  "Pear",
  "Cherry",
  "Banana"

You can use either single or double quotes for string values in YINI.

7. Document Terminator (strict mode)

The /END marker is required only in strict mode, and optional in lenient (default) mode.

End a file explicitly with:

^ App
title = "MyTitle"

/END    // Must be included in strict mode.

8. Disabled Lines

Prefix any valid line with -- to skip it entirely:

--maxRetries = 5

Complete Example

@yini       # Optional marker to identify YINI format.

^ App
name    = "MyApp"
version = "1.0.0"
debug   = off  // Turn on for debugging.

^^ Database
host     = "db.local"
port     = 5432
--user   = "secret"  # This line is disabled due to --.
--userList = ["alice", "bob", "carol"]

/END

Advanced Example

const YINI = require('yini-parser').default; // Or: import YINI from 'yini-parser';

const config = YINI.parse(`
    /*
        This is a multi-line block comment.
    */

    @yini

    ^ App
    name = "Nested Example"
    version = "1.0.0"
    debug = OFF  // This is a comment.

        # Database settings.
        ^^ Database
        host = "db.example.com"
        port = 3306
        user = "appuser"
        --password = "dbpassword"  # Disabled line due to --.
        //password = "dbpassword"  # Not sure yet about this pw.
        password = "dbpassword"  # Keep this secret.

            // Commenting with slashes works too.
            ^^^ Pool
            min = 2
            max = 10
            idleTimeout = 300

        /* Block comment on a single line. */
        ^^ Logging
        level = "info"
        logToFile = ON # This is a comment.
        filePath = "./logs/app.log"

    /END
`);

console.log(config);

Output:

// JS 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"
        }
    }
}

Thanks for reading!

If you like what you read, check out the below too :)

➡️ YINI Parser GitHub Repo
➡️ Blog post: Why I created YINI
➡️ If you have a Node.js project, you might give it a go Official YINI Parser on npm

🤝 Contributing to YINI parser (TypeScript)

We welcome feedback, bug reports, feature requests, and code contributions!

YINI Homepage

Bye, Marko Seppänen (author of YINI)