[WIP] add rw BigInt64 methods

[fanatid]

Original issue #244
This is quick copy code from node. I did not want make everything perfect because have a questions.

Is it ok use let/const/arrow functions/extends/template strings/etc? What if:

1. Package will start use latest syntax and will be transpiled to what should be supported?
2. Package will start use latest syntax and distribute it, so anybody who use it will need traspile to what they actually use? This is not used usually, right? But from my understanding this should give best code for projects who uses buffer, because they will receive only transpiled parts which they not support in their environment.

[lgtm-com]

This pull request introduces 1 alert when merging d8b7133 into c7f5cd7 - view on LGTM.com

new alerts:

• 1 for Expression has no effect

[feross]

Is it ok use let/const/arrow functions/extends/template strings/etc?

If we want to continue supporting IE11 that means we can use:

• let
• const in most places

But should probably avoid the rest.

If we want to use new syntax in the codebase, that would probably let us port code from Node.js more easily, which I like.

But then we need to do one of these two options:

• use new syntax, drop IE11, publish a new major version
• use new syntax, add babel, start shipping a transpiled build

[fanatid]

Why if we add babel we need drop IE11? Not all polyfills work in IE11? Major bump because too much changes?
Projects can not publish not transpiled code because this will be headache for developers who use it?

[feross]

@fanatid I meant that we need to do one of those two option.

If we start using new syntax without babel then this package stops working in IE11 unless users start transpiling it. So that's a breaking change and we need to publish a new major version.

Or, we use new syntax, add babel, and ship a transpiled build. Then no new major version is needed because nothing breaks from the user's perspective.

[vweevers]

It might be harder to optimize a transpiled build for performance?

[feross]

Yeah, true.

I'm happy to just optimize for newer browsers. The current version of buffer works fine in IE11 and folks can always continue using that version if they need IE11 support. We can continue development on a new major version. Let's do it.

[fanatid]

Thanks for explanation Feross.
@vweevers probably yes, but continue manually port new code to old syntax is pain for everybody. Other thing that not traspiled code should be executed faster than manually ported because code should be more effective? (but this will break almost all projects who uses buffer? haha)

So, decision is major version bump with new JS features transpiled for supported browsers? 😄

[feross]

I think we should not transpile. Users can do that if they want. We can release a new major version that includes new language features. We shouldn't get carried away, though. Tests should still pass in the last two major versions of every major browser (Chrome, Firefox, Safari, Edge, Safari on iOS, Chrome on Android).

[java-james]

When do you think we can expect resolution and merge of this PR?

[fanatid]

Sorry, do not have time right now to finish it. Maybe later.

[collincusce]

Heyyy do you have time now? This is a feature I could immediately use! <3

[collincusce]

@fanatid or @feross there's a lot of missing functions in Buffer and classes like, BN.js which has toArrayLike and tries to use Buffer fails. If this fix patches that, can we get it reviewed and merged?

[fanatid]

Can you describe situations (or show examples) when bn.js fails with Buffer?

[collincusce]

Absolutely, I should definitely be more clear. Sorry @fanatid and @feross .. I apologize. Using the current nodejs LTS + Typescript, typechecking fails because these functions are missing. This isn't just about BN.js but also things like elliptic. Using any Buffer as a parameter will give an error. Here's some examples of type conflicts.

All of these I have workarounds for, but most of it is a pretty annoying efficiency hit (like convert from Buffer(node version) to Buffer(js version) or convert to hex before passing to BN etc etc. It would be great if it was a drop-in for the LTS version like it was in the previous LTS version.

Here's a file I built just to handle some of these situations... maybe it'll help you see.

//Singleton, use getInstance()
export class BinTools {
    private static  instance:BinTools;
    private constructor() {}
  
    static getInstance(): BinTools {
        if (!BinTools.instance) {
            BinTools.instance = new BinTools();
        }
        return BinTools.instance;
    }
    copyFrom(buff:Buffer, start:number, end:number){
        return Buffer.from(Uint8Array.prototype.slice.call(buff.slice(start,end)))
    }
    bufferToB58(buff:Buffer) {
        return bs58.encode(Array.prototype.slice.call(buff));
    }

    fromBufferToArrayBuffer(buff:Buffer) {
        let ab = new ArrayBuffer(buff.length);
        let view = new Uint8Array(ab);
        for (let i = 0; i < buff.length; ++i) {
            view[i] = buff[i];
        }
        return ab;
    }
    fromArrayBufferToBuffer(ab:ArrayBuffer) {
        let buf = Buffer.alloc(ab.byteLength);
        let view = new Uint8Array(ab);
        for (let i = 0; i < buf.length; ++i) {
            buf[i] = view[i];
        }
        return buf;
    }

    fromBufferToBN(buff:Buffer){
        return new BN(buff.toString("hex"), 16, "be");
    }

    fromBNToBuffer(bn:BN){
        return Buffer.from(bn.toArray("be"));
    }
}

[fanatid]

Ah, so it's mostly about TypeScript?

[collincusce]

Yes sorry if that's not a roadmap item, but it likely would fix Typescript issues if this push was put in

[collincusce]

Any updates?

[Saiv46]

LGTM, please someone finish it

[kevincfz]

LGTM: Could someone with write access approve these changes please?

[Tschakki]

@feross could you merge this one please? :)

[feross]

I'm okay with shipping a new version of buffer only for modern browsers. We can consider shipping a transpiled version if we want to preserve current browser support, but let's do that in another issue.

@fanatid Do you think this is ready to merge?

[feross]

I just tried running the ES6 browser tests and they throw an exception because the way that assert.throws is used here:

Can someone figure out the cause of this? If you do, please either update this PR (@fanatid) or send a PR to this PR (anyone else).

[collincusce]

I'm okay with shipping a new version of buffer only for modern browsers.

Please! I'm doing so many hokey things to handle Uint64 types lol, and the real barrier here is just getting TypeScript to agree that it's a Buffer class. Without the functions matching, TypeScript balks. Can we make it match the latest nodejs LTS version?

Full disclosure: I can get it to work, but standard libraries which depend on Buffer have issues. So I've had to do things like write my own base58 encoder/decoder.

[fanatid]

Sorry, I do not have a time to check/update changes =(. Will be happy if somebody fork PR with required fixes / changes.

[shuse2]

@feross @fanatid
I forked thie PR and add a commit to original commit in #267 to address the issue #247 (comment)

Running npm run test-browser-es6-local, it does not show the thrown error, and still passes the test.

Please check when you have time

[feross]

Thanks @shuse2 – let's use #267

[feross]

Released as 6.0.0