use native BigInt as option, add always option

[haoadoreorange]

What it does

The following pull-request adds options

{
  "alwaysBigNumber": true,
  "useBigInt": true
}

In order to support native BigInt. The option alwaysBigNumber forces every number to be parsed as BigNumber (in case useBigInt false, use bignumber.js)

Inspired by and possibly closes #30. I changed the options so it is more aligned with existing codes, removed some unecessary part in stringify in the other PR.

[sidorares]

Thanks for the PR, especially for not leaving out documentation changes.

to me new option name useBigInt can be a bit confusing. Maybe nativeBiUnt or useNativeBiInt ? wdyt @babyadoresorange

[haoadoreorange]

I thought about it, the initial name was useNativeBigInt actually. Then I looked and the existing code is using BigNumber (logical as the lib is bignumber.js) so I thought BigInt might be enough. But I forgot that this lib is named json-bigint !

TLDR yeah I think useNativeBigInt is great.

Also, I included the change from #28, which was to improve speed and memory usage, but changes nothing on the behaviour. Does that bother you ?

[haoadoreorange]

On a side note, why the BigNumber is set to null at the beginning in parse ?

[sidorares]

On a side note, why the BigNumber is set to null at the beginning in parse ?

are you asking why bother setting it to null instead of leaving undefined? Can't remember, probably can be declared without initialization.

If the question "why is not required at the beginning" - my thinking was "if 99.9 of my data is with JS floating point range, maybe it's better delay loading of bignumber.js to improve startup time / memory footprint."

[sidorares]

Also, I included the change from #28, which was to improve speed and memory usage, but changes nothing on the behaviour. Does that bother you ?

no, that's fine. There are few neglected PRs unfortunately, I need to find time to merge or close them

[haoadoreorange]

On a side note, why the BigNumber is set to null at the beginning in parse ?

are you asking why bother setting it to null instead of leaving undefined? Can't remember, probably can be declared without initialization.

If the question "why is not required at the beginning" - my thinking was "if 99.9 of my data is with JS floating point range, maybe it's better delay loading of bignumber.js to improve startup time / memory footprint."

Good point.

On terminology, do you think alwaysBigNumber isn't clear either ? Maybe something like alwaysParseAsBig.

There is also one thing I want to add in the document. Currently there is a limitation, s === stringify(parse(s)) but o !== parse(stringify(o)) when we have something like 123n. There is currently no consistent way to deal with it afaik so better just leave it like that with notice imho.

[haoadoreorange]

Done ! updated as discussed

[haoadoreorange]

Do you have due date for merge and publish npm ? I would like to have this merge as a dependency

[sidorares]

@babyadoresorange published json-bigint@0.4.0