-
Notifications
You must be signed in to change notification settings - Fork 190
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
use native BigInt as option, add always option #36
Conversation
Thanks for the PR, especially for not leaving out documentation changes. to me new option name |
I thought about it, the initial name was TLDR yeah I think 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 ? |
On a side note, why the |
are you asking why bother setting it to 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." |
no, that's fine. There are few neglected PRs unfortunately, I need to find time to merge or close them |
Good point. On terminology, do you think There is also one thing I want to add in the document. Currently there is a limitation, |
Done ! updated as discussed |
Do you have due date for merge and publish npm ? I would like to have this merge as a dependency |
@babyadoresorange published |
What it does
The following pull-request adds options
In order to support native BigInt. The option
alwaysBigNumber
forces every number to be parsed as BigNumber (in caseuseBigInt
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.