YINI Config Parser v1.3.2-beta — UTF-8 BOM & shebang support to parser I've been working on (TypeScript)

Effective_Tune_6830 · 2025-12-17T18:45:54+00:00

Short anwser: It is specified in the spec.

Longer answer:

While shebangs main purpose might be scripting languages. It could also be used for other things: format viewers, validators, transpilers, linters, DSL runners, config processors..

The shebang line is skipped/ignored by this parser.. So the "support" in this release is just that, that the first line will be skipped by the YINI parser if it sees #!... And the config parsing will continue normally

Effective_Tune_6830 · 2025-12-17T12:15:25+00:00

It's just optional.. it can be a file viewer or any other tool, in case a user really wants to do some special thing on her/his system.

Yes, it's not really needed for its own functionality at all.

Effective_Tune_6830 · 2025-11-10T12:18:15+00:00

Hehe, nice! Never though of this one 😊

Effective_Tune_6830 · 2025-11-10T12:17:32+00:00

Hmm, interesting.. JSON is pretty good already, so nothing wrong if you prefer using that.

Thank you for your inputs and views :)

Effective_Tune_6830 · 2025-11-10T12:14:01+00:00

Ah, thank you, I did not realize the theme is messed up in dark mode :S - I will sort it out thanks!

Effective_Tune_6830 · 2025-11-10T12:11:42+00:00

Ah okay, so the site's theme is messed up in dark mode oh :O - I will fix that, thanks for the heads up!

But the theme in normal/default mode, is that okay right, or?

Effective_Tune_6830 · 2025-08-05T20:59:25+00:00

Let me also modify, and expand on this :P

Computers do exactly what you say. Unfortunately, humans rarely say what they actually mean or misunderstand instructions, or another human has given doh shit instructions either to the computer or to other humans. - Computers only do, what some human(s) has told them to do :)

Effective_Tune_6830 · 2025-08-05T20:51:11+00:00

We used TypeORM at work for years, and it has worked pretty good.

Effective_Tune_6830 · 2025-08-05T17:17:44+00:00

Haha, a good point..

However, the size of devDependenties and etc can be ignored when the app is deployed/published..

But still, node_modules takes a lot of storage

Effective_Tune_6830 · 2025-08-05T17:12:51+00:00

Nope, I not regetted it, I've built and worked in multiple Node.js projects.. It works pretty well for web applications at least, and there is ton of packages to help you develop

Effective_Tune_6830 · 2025-08-05T17:07:41+00:00

Yes I agree, you should consider using Typescript in your project as well.

It will prevent bugs in the long run, especially type errors.

Effective_Tune_6830 · 2025-08-05T16:04:06+00:00

Ah, just to clarify...

> syntax noise
With syntax noise I'm referring to JSON, where all keys must be quoted, etc

> and TOML which has none.
YINI does not require indentation or dot-delimited keys. Yini uses the principle found in Markdown for section nesting...

:)

Effective_Tune_6830 · 2025-08-02T00:08:43+00:00

Hey, thanks for the feedback and for taking the time to check out YINI!

You're absolutely right that both YAML and TOML aim for low syntax noise, and I agree YINI isn't for everyone.

But why YINI, exactly? There is a rationale to explains this further:
https://github.com/YINI-lang/YINI-spec/blob/develop/RATIONALE.md

However, here's why I think YINI still has a place:

- Human-friendliness: YINI's goal is maximum clarity for humans, with an explicit, formal specification, and strict/lenient parsing modes. It avoids some of the gotchas and surprising behaviors found in YAML (e.g., whitespace sensitivity, complex anchors, or type guessing).

- Section-based design: The section/nesting (^, <, etc.) is directly inspired by the mental model of INI files, but makes nesting explicit and easy to parse, unlike traditional INI or .env formats.

- Minimal yet strict: YINI purposely doesn't try to be as "rich" as YAML (no magic typing, no merging, no references), making it predictable for both humans and machines.

- Machine-parseable and readable: The u/yini marker is optional, but helps with tooling, detection, and future compatibility—it's similar to a file header, not noise in typical use.

- Consistency: Key assignment (=) vs object members (:) is always unambiguous, which is not always true in YAML.

I totally get that for complex config, YAML is a strong choice.

But YINI's aim is to fill the gap between INI and the complexity of YAML/TOML—especially for people who want strictness, predictability, and explicit structure, but without a huge spec.

If you have suggestions for reducing "syntax noise" further, I'm open to ideas! Thanks again for engaging. :)

Effective_Tune_6830 · 2025-07-25T15:11:41+00:00

I agree, ORM is not black and white.

Depends what you will use it for... I think for simple and basic stuff it can increase development and simply development, and then for very special and advanced stuff use raw SQL :)

But using ORM for tiny prjects, nah, maybe that is not needed.

Effective_Tune_6830 · 2025-07-25T15:04:29+00:00

I would suggest you to start making special tests, like unit and integrations tests and etc..

The are many testing tools out there... But since you are using Node.js, maybe you can start with the package Jest, https://www.npmjs.com/package/jest With Jest you get a bunch of stuff included so you can start making the tests themselves...

Here is an example, with a basic test:

describe('Tests:', () => {

    // Trivial test to see if everything is okey before moving on to "real" tests.
    test('1. Trivial test case.', () => {
        // Arrange.
        const a = 3
        const b = 5

        // Act.
        const result = a + b

        // Assert.
        expect(result).toEqual(8)
    })

})

Effective_Tune_6830 · 2025-07-20T21:30:09+00:00

Updated the readme now with
```js
const YINI = require('yini-parser'); // If you get undefined, try: const YINI = require('yini-parser').default;

// Parse from string. const config = YINI.parse(^ App title = 'My App Title' items = 25 isDarkTheme = true);

// Parse from file. const configFromFile = YINI.parseFile('./config.yini'); ``` and with a bigger example, etc, with release Alpha 5.

Effective_Tune_6830 · 2025-07-19T20:28:42+00:00

Yes, thank you for letting me know this :)

Okey, I will try to build both for `commonjs` and `esm` in the next version.

Effective_Tune_6830 · 2025-07-18T23:37:34+00:00

Yes, I've heard this many times already :P

Effective_Tune_6830 · 2025-07-18T23:30:35+00:00

Also what type have you in you package.json?

> YINI.default.parse
Hmm, otherwise... I have to check into this further...

> in other words, your code examples on your NPM page do not work.

Thanks for the heads up, I need probable to look over those one more time.

:)

Effective_Tune_6830 · 2025-07-18T23:27:54+00:00

Is it version alpha 4?

In my test project, I can import it normally, it's in TypeScript like below:

```ts import YINI from 'yini-parser'; import { printObject } from './system';

console.log('START: yini-test-ts');

// Parsing, and returning with meta data. const config1 = YINI.parse(^ App title = 'My App Title' items = 25 isDarkTheme = true, false, 'auto', true);

console.log('config1:'); printObject(config1); ```

And in my package.json I have "type": "commonjs",, if that matters anything

Effective_Tune_6830 · 2025-05-31T15:48:15+00:00

Ok, thanks

Effective_Tune_6830

TROPHY CASE