Code Monkey home page Code Monkey logo

jsbi's Introduction

JSBI — pure-JavaScript BigInts Build status jsbi on npm

JSBI is a pure-JavaScript implementation of the ECMAScript BigInt proposal, which officially became a part of the JavaScript language in ES2020.

Installation

npm install jsbi --save

Usage

import JSBI from './jsbi.mjs';

const max = JSBI.BigInt(Number.MAX_SAFE_INTEGER);
console.log(String(max));
// → '9007199254740991'
const other = JSBI.BigInt('2');
const result = JSBI.add(max, other);
console.log(String(result));
// → '9007199254740993'

Note: explicitly call toString on any JSBI instances when console.log()ing them to see their numeric representation (e.g. String(max) or max.toString()). Without it (e.g. console.log(max)), you’ll instead see the object that represents the value.

Use babel-plugin-transform-jsbi-to-bigint to transpile JSBI code into native BigInt code.

Refer to the detailed instructions below for more information.

Why?

Native BigInts are already shipping in modern browsers (at the time of this writing, Google Chrome 67+, Opera 54+, Firefox 68+, Edge 79+, Safari 14+) and Node.js (v10.4+), but some users are still running older browsers — which means you can't use them yet if you want your code to run everywhere.

To use BigInts in code that you want to run everywhere, you need a library. But there’s a difficulty: the BigInt proposal changes the behavior of operators (like +, >=, etc.) to work on BigInts. These changes are impossible to polyfill directly; and they are also making it infeasible (in most cases) to transpile BigInt code to fallback code using Babel or similar tools. The reason is that such a transpilation would have to replace every single operator in the program with a call to some function that performs type checks on its inputs, which would incur an unacceptable performance penalty.

The solution is to do it the other way round: write code using a library’s syntax, and transpile it to native BigInt code when available. JSBI is designed for exactly this purpose: it provides a BigInt “polyfill” implementation that behaves exactly like the upcoming native BigInts, but with a syntax that you can ship on all browsers, today.

Its advantages over other, existing big-integer libraries are:

  • it behaves exactly like native BigInts do where they are available, so to eventually migrate to those, you can mechanically update your code’s syntax; no re-thinking of its logic will be required.
  • strong focus on performance. On average, JSBI is performance-competitive with the native implementation that Google Chrome is currently shipping. (Note: we expect this statement to gradually become outdated as browsers invest in additional optimizations.)

How?

Except for mechanical differences in syntax, you use JSBI-BigInts just like you would use native BigInts. Some things even look the same, after you replace BigInt with JSBI.BigInt:

Operation native BigInts JSBI
Creation from String a = BigInt('456') a = JSBI.BigInt('456')
Creation from Number a = BigInt(789) a = JSBI.BigInt(789)
Conversion to String a.toString(radix) a.toString(radix)
Conversion to Number Number(a) JSBI.toNumber(a)
Truncation BigInt.asIntN(64, a) JSBI.asIntN(64, a)
BigInt.asUintN(64, a) JSBI.asUintN(64, a)
Type check typeof a === 'bigint' a instanceof JSBI

Most operators are replaced by static functions:

Operation native BigInts JSBI
Addition c = a + b c = JSBI.add(a, b)
Subtraction c = a - b c = JSBI.subtract(a, b)
Multiplication c = a * b c = JSBI.multiply(a, b)
Division c = a / b c = JSBI.divide(a, b)
Remainder c = a % b c = JSBI.remainder(a, b)
Exponentiation c = a ** b c = JSBI.exponentiate(a, b)
Negation b = -a b = JSBI.unaryMinus(a)
Bitwise negation b = ~a b = JSBI.bitwiseNot(a)
Left shifting c = a << b c = JSBI.leftShift(a, b)
Right shifting c = a >> b c = JSBI.signedRightShift(a, b)
Bitwise “and” c = a & b c = JSBI.bitwiseAnd(a, b)
Bitwise “or” c = a | b c = JSBI.bitwiseOr(a, b)
Bitwise “xor” c = a ^ b c = JSBI.bitwiseXor(a, b)
Comparison to other BigInts a === b JSBI.equal(a, b)
a !== b JSBI.notEqual(a, b)
a < b JSBI.lessThan(a, b)
a <= b JSBI.lessThanOrEqual(a, b)
a > b JSBI.greaterThan(a, b)
a >= b JSBI.greaterThanOrEqual(a, b)

The functions above operate only on BigInts. (They don’t perform type checks in the current implementation, because such checks are a waste of time when we assume that you know what you’re doing. Don’t try to call them with other inputs, or you’ll get “interesting” failures!)

Some operations are particularly interesting when you give them inputs of mixed types, e.g. comparing a BigInt to a Number, or concatenating a string with a BigInt. They are implemented as static functions named after the respective native operators:

Operation native BigInts JSBI
Abstract equality comparison x == y JSBI.EQ(x, y)
Generic “not equal” x != y JSBI.NE(x, y)
Generic “less than” x < y JSBI.LT(x, y)
Generic “less than or equal” x <= y JSBI.LE(x, y)
Generic “greater than” x > y JSBI.GT(x, y)
Generic “greater than or equal” x >= y JSBI.GE(x, y)
Generic addition x + y JSBI.ADD(x, y)

The variable names x and y here indicate that the variables can refer to anything, for example: JSBI.GT(101.5, BigInt('100')) or str = JSBI.ADD('result: ', BigInt('0x2A')).

Unfortunately, there are also a few things that are not supported at all:

Unsupported operation native BigInts JSBI
literals a = 123n; N/A ☹
increment a++ N/A ☹
a + 1n JSBI.add(a, JSBI.BigInt('1'))
decrement a-- N/A ☹
a - 1n JSBI.subtract(a, JSBI.BigInt('1'))

It is impossible to replicate the exact behavior of the native ++ and -- operators in a polyfill/library. Since JSBI is intended to be transpiled away eventually, it doesn’t provide a similar-but-different alternative. You can use JSBI.add() and JSBI.subtract() instead.

Since version 4.2.0, polyfills for DataView operations are included (where dv is a DataView, i is an index, le is an optional boolean indicating little endian mode, and x is a BigInt or a JSBI instance, respectively):

native BigInts/DataViews JSBI
dv.getBigInt64(i, le) JSBI.DataViewGetBigInt64(dv, i, le)
dv.setBigInt64(i, x, le) JSBI.DataViewSetBigInt64(dv, i, x, le)
dv.getBigUint64(i, le) JSBI.DataViewGetBigUint64(dv, i, le)
dv.setBigUint64(i, x, le) JSBI.DataViewSetBigUint64(dv, i, x, le)

When?

Now! The JSBI library is ready for use today.

Once BigInts are natively supported everywhere, use babel-plugin-transform-jsbi-to-bigint to transpile your JSBI code into native BigInt code once and for all.

View our issue tracker to learn more about out our future plans for JSBI, and please join the discussion!

A more vague future plan is to use the JSBI library (or an extension to it) as a staging ground for additional BigInt-related functionality. The official proposal is intentionally somewhat minimal, and leaves further “library functions” for follow-up proposals. Examples are a combined exp+mod function, and bit manipulation functions.

Development

  1. Clone this repository and cd into the local directory.

  2. Use the Node.js version specified in .nvmrc:

    nvm use
  3. Install development dependencies:

    npm install
  4. Run the tests:

    npm test

    See npm run for the list of commands.

For maintainers

How to publish a new release

  1. On the main branch, bump the version number in package.json:

    npm version patch -m 'Release v%s'

    Instead of patch, use minor or major as needed.

    Note that this produces a Git commit + tag.

  2. Push the release commit and tag:

    git push && git push --tags

    Our CI then automatically publishes the new release to npm.

jsbi's People

Contributors

12wrigja avatar alexendoo avatar futpib avatar gaubee avatar goloroden avatar jakobkummerow avatar janhommes avatar kmalakoff avatar leslie-wong-h avatar mathiasbynens avatar s-cork avatar yaffle avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

jsbi's Issues

[discussion] migration

The idea of migration is mentioned in README and I'm interested. I did some quick search. Candidates:

Actually I would prefer an Editor plugin, since it will typically only be used once in a project.

Possibly broken in IE11

I noticed that JSBI is broken in a test application when running in IE11.

When I exclude JSBI in webpacks babel-loader exclude (jsbi is parsed like the rest of my code):

grafik
This possibly points to:

if (!_(t) || i(t) !== t) throw new RangeError("The number " + t + " cannot be converted to BigInt because it is not an integer");

I use core-js@3 and regenerator-runtime as polyfills. Maybe I need something else as well?

When I do not exlude JSBI and treat it like any other dependency (jsbi is included in babel-loader):
grafik
This time it is unfortunately absolutely impossible to tell what upsets poor IE. Maybe its the same statement, who knows 🤷‍♂️.

Is the UMD version tested? Works fine in Firefox 80, but not in IE11.

I also noticed #42. I tested importing the common-js and mjs versions directly, however I still get similar results. IE is broken while Firefox works.

transpile the UMD to ES5

We have an issue with a library that imports JSBI and should be used in a browser. Especially it fails in IE11 because of >ES5 syntax used here:
https://unpkg.com/[email protected]/dist/jsbi-umd.js

Just wanted to know if there is any reason why the UMD module is not traspiled to ES5? That would make the usage of libraries much easier, especially as the Rollup documentation says that all external dependencies should be transpiled already when you using it with babel.

The lib and the PR is: vasturiano/ip.js#1

Thanks
Jan

Create a JSBI → BigInt transpiler

Most features are transpiled from their standardized form into a more compatible form. For BigInt specifically, this is not feasible for the reasons outlined in the README.

As such, developers wishing to use BigInt functionality today should instead use JSBI to write their code. Then, when the time comes that BigInts are natively supported everywhere, they should be able to transpile their JSBI-based code into native BigInt code.

In other words, we need a JSBI → native BigInt transpiler.

If you’d like to help, please speak up!

Update: @FWeinb created a prototype Babel plugin. What’s left to do is for someone to take that code, package it up as its own repository with tests and publish it as an npm module.

asIntN appears to give wrong value

var JSBI =require('jsbi');

a = JSBI.BigInt('-2562362345234747635679540932095783458054366');

b=JSBI.asUintN(20, a);
c=JSBI.asIntN(20, a);

console.log(b.toString());
console.log(c.toString());

/* output:

   515874
   515874

*/

Or maybe I don't understand how it is supposed to work.

Consider switching internal storage to 30 bits per digit

As of Chrome 80 (V8 8.0 branch), V8's "pointer compression" technique has required it to use "31-bit Smis" under the hood, which means that JSBI's chosen internal representation of 32 bits per digit is now a lot less efficient than it was before (in terms of both memory and CPU). It might be worth switching to 30 bits per digit, if enough people care about JSBI's efficiency (when it isn't compiled to native BigInts with the Babel plugin).

(As an alternative, we could move to 50 or so bits per digit to at least make more efficient use of doubles, but my intuition is that the required double<->int conversions would be too costly.)

JSBI Instance's prototype lost when passed as a message via window.postMessage API

If post a JSBI.BigInt object via window.postMessage like this:

window.postMessage({ bi: JSBI.BigInt(1) });

In the other side, the received bi attribute will be a plain JavaScript Object instead of a JSBI.BigInt instance. bi instanceof JSBI will return false.

If I pass the received bi as a param of JSBI.add like this:

JSBI.add(bi, JSBI.BigInt(1))

The below error will throw:

TypeError: e.__clzmsd is not a function

Have a look into window.postMessage API Doc:

message
Data to be sent to the other window. The data is serialized using the structured clone algorithm. This means you can pass a broad variety of data objects safely to the destination window without having to serialize them yourself. [1]

The structured clone algorithm will serialize JSBI Object to a plain JavaScript Object, so the prototype will certainly lost.

The structured clone algorithm support the new native BigInt type. But If I want use JSBI as a polyfill of the new native BigInt in a window.postMessage case, any solution to this problem?

Symbol.toPrimitive doesn't exist in IE11

jsbi/lib/jsbi.ts

Lines 1764 to 1769 in c80c3ae

const exoticToPrim = obj[Symbol.toPrimitive];
if (exoticToPrim) {
const primitive = exoticToPrim(hint);
if (typeof primitive !== 'object') return primitive;
throw new TypeError('Cannot convert object to primitive value');
}

My understanding is that this code won't work in IE11 as neither Symbol or Symbol.toPrimitive are defined there.

Is using toPrimitive necessary, or could it be removed? If it is needed, then I would suggest wrapping it in some typeof checks:

if (typeof Symbol !== "undefined" && typeof Symbol.toPrimitive === "symbol" ) {
   ... existing code here ...
}

I can send a PR for the above, but wanted to check and see whether this code is even needed before continuing down this path.

Serialization to Uint8Array.

Are there any functions available in the library to write a BigInt to a DataView? Or perhaps retrieve a Uint8Array from a BigInt instance?

Looking to polyfill for: DataView.getBigUint64(byteOffset, littleEndian).

SQRT

Hi is there any way to do the sort of a JSBI number?

v4.2.2 and v4.3.0 tags

Whilst following the instructions in the README, I accidentally pushed tags for both v4.2.2 and v4.3.0 (as I hadn't realized that the old tag wasn't deleted when I reset my working directory state back to upstream main).

I was able to cancel the publish workflow for v4.2.2 (but v4.3.0 has been published).

Thoughts on how to reconcile this?

Improve test coverage

The current implementation has been tested quite well, but even more rigorous testing is always possible.

Should you find any bugs, please report them!

README.md typo

It says on line 62 Modulus where it should be read as Remainder, as there isn't a modulus operator in JS.
Please note that remainder and modulus may seem to be idempotent, but it's only true over natural numbers, for integers modulus differ from remainder when dividend is negative.
Ex:

-3 % 4 === -3
modulus(-3, 4) === 1

I would open a PR, but i ain't willing to sign a CLA.

Thanks,

Add repository field to npm package

https://www.npmjs.com/package/jsbi does not link to this repository,
even though the “Development” section of its readme includes the
instructions, “close this repository.” As far as I can tell, the only
way to connect this repository to that package is by searching for “jsbi
github” with your favorite search engine.

(-(2n**64n - 1n)) >> 32n

JSBI.signedRightShift(JSBI.unaryMinus(JSBI.subtract(JSBI.exponentiate(JSBI.BigInt(2), JSBI.BigInt(64)), JSBI.BigInt(1))), JSBI.BigInt(32)).toString()
gives "0"
which is wrong, seems

Error: Convert JSBI instances to native numbers using `toNumber`

After updating to 4.1.0 release, getting the following error:

Stack trace:

"Error: Convert JSBI instances to native numbers using toNumber."," at JSBI.valueOf (/var/task/index.js:96308:1240)"," at new Number ()"," at new newClass (/var/task/index.js:96385:13)"," at new Decimal (/var/task/index.js:185797:9)"," at _loadValue (/var/task/index.js:206751:20)"," at _loadStruct (/var/task/index.js:206781:47)"," at _loadValue (/var/task/index.js:206767:20)"," at _loadStruct (/var/task/index.js:206781:47)"," at _loadValue (/var/task/index.js:206767:20)"," at _loadSequence (/var/task/index.js:206799:23)"]}}}

Code:

{
amount: {
value: charge.get('cost', 'value')?.numberValue(),
currency: charge.get('cost', 'currency')?.stringValue(),
},
};

where charge is of type https://github.com/amzn/ion-js/blob/master/src/dom/Value.ts#L22

Karatsuba algorithm for bigint multiplication

Hi,

I was wondering if a faster algorithm for bigint multiplication could be used for large bigints. The Karatsuba algorithm is relatively simple, so it wouldn't increase the code size by much while being significantly faster. I would love to contribute code for this. (Though I'm not sure what algorithm the project already uses!)

Export functions instead of static methods

The library is quite big and it cannot be tree shaken because all of the operators are static methods.
It would be nice to have them exported from module, so unused operators could be removed from final bundle, after all we all want faster web.
Chances are you won't be using many operators like bitwise operations.
In my case, I would like to use BigInt for operations on money and I really need only basic operations.

Incorrect bitwiseAnd result

The following code demonstrates the issue and compares the result against native BigInt implementation:

const a = "0b10000010001000100010001000100010001000100010001000100010001000100";
const b = "0b10000000000000000000000000000000000000000000000000000000000000000";

const jsbiRes = JSBI.bitwiseAnd(JSBI.BigInt(a), JSBI.bitwiseNot(JSBI.BigInt(b)));
const nativeRes = BigInt(a) & ~BigInt(b);

console.log("A:", a);
console.log("B:", b);
console.log("JSBI A & ~B:", jsbiRes.toString(2));
console.log("Native A & ~B:", nativeRes.toString(2));

This is the output I get running in Node v12.16.3 using JSBI v3.1.2:

A: 0b10000010001000100010001000100010001000100010001000100010001000100
B: 0b10000000000000000000000000000000000000000000000000000000000000000
JSBI A & ~B: 10000010001000100010001000100010001000100010001000100010001000100
Native A & ~B: 10001000100010001000100010001000100010001000100010001000100

Does not work like BigInt

Wanted to use jsbi for max backward compatibility, so I converted code I was using previously for BigInt with IPv6 addresses, but the result I am getting from jsbi is quite different:

const v6ip = '2001:067c:02e8:0000:0000:0000:0000:0000'
const v6ipcalcJSBI = JSBI.BigInt('0x' + v6ip.toLowerCase().split(':').map(v => v.padStart(4, 0)).join(''))
const v6ipcalcBI = BigInt('0x' + v6ip.toLowerCase().split(':').map(v => v.padStart(4, 0)).join(''))
console.log(v6ipcalcJSBI, v6ipcalcBI)

gives log result of:

JSBI(5) [0, 0, 780140544, 4300544, 32, sign: false] 42540619681625057249144045814239199232n

I thought this was supposed to be a drop in replacement, is that correct?

Assign -1 to BigInt, but BigInt return 18446744073709552000

Hi, JSBI is a very good API for me, but I am confused in following case.

In offical web site say

Another thing to note is that the >>> operator, which performs an unsigned right shift, does not make sense for BigInts since they’re always signed. For this reason, >>> does not work for BigInts.

So, I assume the following code should have same result, why they are different?

let max = JSBI.BigInt("0xffffffffffffffff");
console.log(`${JSBI.toNumber(max)} ==? ${max.toString(16)}`);
let num_m1 = JSBI.BigInt("-1");
console.log(`${JSBI.toNumber(num_m1)} ==? ${max.toString(16)}`);

results:

[Log] 18446744073709552000 ==? ffffffffffffffff (main.chunk.js, line 1293)
[Log] -1 ==? ffffffffffffffff (main.chunk.js, line 1295)

Very thanks.

The remainder method returns wrong result for some values

const jsbi = require('jsbi');

const a = '2788589391528142331873770897124985830679715361908029740727468171087321981075';
const b = '170141183460469231731687303715884105727';

console.log('wrong:', jsbi.remainder(jsbi.BigInt(a), jsbi.BigInt(b)).toString());
console.log('correct', BigInt(a) % BigInt(b));

CJS Module will not work on browser due to different JSBI's build target

JSBI has different builds depending on the environment:

  "main": "dist/jsbi-cjs.js",
  "module": "dist/jsbi.mjs",
  "browser": "dist/jsbi-umd.js",

when the "module" or "browser" targets are used the CJS modules that depend on JSBI will break with an error of JSBI.BigInt is not a Function.

What would you advise so that a CJS library can safely work with JSBI in all environments?

JSBI with bigints

Posting here since it might be useful to someone else, it's something I've used in a project that seems to be working well.
(someone will probably tell me why this is a bad idea 😅 )

It has the benefit of being able to use bigint when it's available and JSBI when it's not.

export const JSBI = window.BigInt !== undefined ? {} : require("jsbi");

if (window.BigInt !== undefined) {
    Object.assign(JSBI, {
        BigInt: window.BigInt,
        toNumber: (x) => Number(x),
        toString: (x) => x.toString(),
        unaryMinus: (x) => -x,
        bitwiseNot: (x) => ~x,
        bitwiseAnd: (x, y) => x & y,
        bitwiseOr: (x, y) => x | y,
        bitwiseXor: (x, y) => x ^ y,
        exponentiate: (x, y) => x ** y, // you may need to adjust this (like i did) if your transpiler changes it to Number.pow
        multiply: (x, y) => x * y,
        divide: (x, y) => x / y,
        remainder: (x, y) => x % y,
        add: (x, y) => x + y,
        subtract: (x, y) => x - y,
        leftShift: (x, y) => x << y,
        signedRightShift: (x, y) => x >> y,
        unsignedRightShift: (x, y) => x >>> y, // will raise TypeError
        lessThan: (x, y) => x < y,
        lessThanOrEqual: (x, y) => x <= y,
        greaterThan: (x, y) => x > y,
        greaterThanOrEqual: (x, y) => x >= y,
        equal: (x, y) => x === y,
        notEqual: (x, y) => x !== y,
    });
}

String parser accepts some corrupt data.

I need fractions for an app so I checked if I could use this lib.

> jsbi.BigInt(" 123234 ")
JSBI [ 123234, sign: false ]
> jsbi.BigInt(" 123234x")
Thrown:
SyntaxError: Cannot convert  123234x to a BigInt
> jsbi.BigInt(" 123234 x")
JSBI [ 123234, sign: false ]
> jsbi.BigInt(" 123234 ?")
JSBI [ 123234, sign: false ]
> jsbi.BigInt(" 123234 ?a")
Thrown:
SyntaxError: Cannot convert  123234 ?a to a BigInt

Why JSBI is subclass of Array?

Array.isArray(JSBI.BigInt('9007199254740992')); // true

This is very inconvenient for serialization libraries.
The order in which the type is determined during encoding can have a significant impact on performance. Codecs / transformers are usually used last, after isArray check.

Maximum BigInt size exceeded

→ node -e "console.log(BigInt('12341234123412341234'))"

12341234123412341234n
→ node -e "new (require('jsbi'))('12341234123412341234')"

RangeError: Maximum BigInt size exceeded
    at new JSBI (/home/futpib/tmp/node_modules/jsbi/dist/jsbi-cjs.js:1:85)
    at [eval]:1:1
    at Script.runInThisContext (vm.js:126:20)
    at Object.runInThisContext (vm.js:316:38)
    at Object.<anonymous> ([eval]-wrapper:9:26)
    at Module._compile (internal/modules/cjs/loader.js:936:30)
    at evalScript (internal/process/execution.js:80:25)
    at internal/main/eval_string.js:23:3

Does not this defeat the purpose of BigInt?

README claims this is "an implementation of the official ECMAScript BigInt proposal", this is clearly not the case.

Invalid sourcemap due to missing TS output files in package

While diagnosing and fixing js-temporal/temporal-polyfill#192, I found that JSBI has the same bug: the package's sourcemap points to files that don't exist in the package. This causes debug console errors in some environments like the VSCode debugger.

For example, here's what I see in the debug console when I run my JSBI-using app in the VSCode debugger:

Could not read source map for file:///Users/[redacted for privacy]/node_modules/jsbi/tsc-out/jsbi.mjs: ENOENT: no such file or directory, open '/Users/[redacted for privacy]/node_modules/jsbi/tsc-out/jsbi.js.map'

The fix that I proposed in js-temporal/temporal-polyfill#193 is to add the tsc-out folder to the package. The lib folder should also be added. I suspect that the same fix may work here too. There may be other fixes possible too.

Introduce shorthands for operations?

If there’s demand for it, we could consider introducing shorthands for operations (e.g. exp for exponentiate, and so on). The current method names follow the spec proposal.

If you have suggestions for naming schemes, please speak up here!

UMD version is used when bundled with Webpack

I'm building an app that targets only new browsers but when I import JSBI from 'jsbi' Webpack uses the UMD bundle because the browser field from package.json takes precedence over module field. My understanding was that the browser field was used only for packages that implement browser-specific code (using browser APIs). Is there a reason why an UMD build is needed these days given how widely used code bundlers are?

This is not a big deal now since the UMD version is only slightly bigger but will become more relevant if #22 gets resolved (UMD build won't work with tree-shaking).

JSBI.EQ implementation bug

JSBI.EQ(JSBI.BigInt(Number.MAX_SAFE_INTEGER), Number.MAX_SAFE_INTEGER)

The above code leads to an implementation bug

I've also found a couple of edge cases:

JSBI.EQ(JSBI.BigInt(18014398509481980), 18014398509481980)
JSBI.EQ(JSBI.BigInt(18014398509481982), 18014398509481982)
JSBI.EQ(JSBI.BigInt(18014398509481988), 18014398509481988)
// false (expected true)

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.