BREAKING(ini): parse understands booleans, undefined, null and numbers

[WasixXD]

Closes #4806

[CLAassistant]

All committers have signed the CLA.

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 96.48%. Comparing base (45be5d3) to head (915ec94).
Report is 29 commits behind head on main.

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #6121      +/-   ##
==========================================
- Coverage   96.57%   96.48%   -0.10%     
==========================================
  Files         535      538       +3     
  Lines       40583    40974     +391     
  Branches     6094     6165      +71     
==========================================
+ Hits        39195    39534     +339     
- Misses       1344     1396      +52     
  Partials       44       44              

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[babiabeo]

Why not just use !isNaN(value)?

[WasixXD]

There's no particular reason, I just put it that way out of habit
Edit: I just checked and isNaN expects a number, so there's no way to use !isNaN(value)

[kt3k]

This allows expression like 1e3 as parsed as number, and it results 1. Is that intentional?

[WasixXD]

Not at all, but its because the parseInt function just returns the first complete integer that it finds on the string. So IsNaN says that value is a number but parseInt can just parse the 1, but easy fix

[babiabeo]

Edit: I just checked and isNaN expects a number, so there's no way to use !isNaN(value)

Oh you're right. I forgot we're using typescript not javascript lol

Edit: BTW I'm curious about the check !value.includes('"'). What is it used for?

[WasixXD]

If its a number but has a " the user wants as a string and not as a number

[babiabeo]

Fair enough

[kt3k]

Can you also work on stringify?

[WasixXD]

yeah sure no problem

[kt3k]

I think these value interpretations are fine because they are very natural in JavaScript, and I guess they probably gave least surprise to the users. LGTM

Note: There's no official specifications for INI format, and major parsers are very incompatible with each other. So we need to choose one way of parsing them, and I find this one is enough reasonable.

[iuioiua]

AFAIK, this functionality is all that remains for stabilising ini.

[kt3k]

Discussed this internally and we'd like to drop the interpretation of undefined literal as there's no other known parsers which parse "undefined" to undefined. (I pushed the commit 915ec94 to this branch)

What do you think?

[WasixXD]

thats ok, this comes closer to what JSON.parse do

[kt3k]

Ok. Let's go with this