Skip to content
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

Allow alternative implementations of BigInt compatibility libraries #3

Open
12wrigja opened this issue Jul 8, 2021 · 11 comments
Open

Comments

@12wrigja
Copy link
Contributor

12wrigja commented Jul 8, 2021

Currently, the polyfill makes heavy use of the big-integer library to polyfill native BigInt. It would be preferable if this support library could be wrapped behind an interface and alternative implementations could be used instead.

@ptomato
Copy link
Contributor

ptomato commented Jul 8, 2021

Would it work for your purposes if the polyfill used native BigInt directly, or do you need to support environments that don't have it?

@12wrigja
Copy link
Contributor Author

12wrigja commented Jul 8, 2021

We will need to support IE11, so using BigInt directly won't work for us.

@12wrigja
Copy link
Contributor Author

12wrigja commented Jul 8, 2021

Pondering this more, this would also be an issue for usage of the Intl APIs, though without having looked over the implementation much maybe there's not a large variety of API surface needed from both, and so accessing those APIs indirectly wouldn't be too much of a hassle.

@ptomato
Copy link
Contributor

ptomato commented Jul 9, 2021

JSBI might be an option, since that's already an interface that is designed to be transpiled into native BigInt operations when applicable. We looked at it last year but decided not to adopt it due to already having big-integer, but maybe now this is a good reason to proceed with it?

@12wrigja
Copy link
Contributor Author

I've spoken with the JSBI maintainers and they are onboard to review a migration of the JSBI source to TypeScript, which I'm undertaking now.

JSBI is designed to be transpiled to native BigInt calls via a Babel plugin which sounds good for code-size assuming that this isn't already happening for big-integer.

@12wrigja
Copy link
Contributor Author

Though I'd prefer to see GoogleChromeLabs/jsbi#22 resolved and use JSBI as if it exported top-level functions. It's unclear to me at the moment whether that change is something that can be done in a backwards-incompatible way and work correctly with the rewriting plugin.

@ptomato
Copy link
Contributor

ptomato commented Aug 10, 2021

(the big-integer calls are definitely not being transpiled, they are wrappers around the native BigInt calls, so this would be a good improvement)

@Pyrolistical
Copy link

Shouldn't we go the other way? Have the source implemented with native BigInt and direct people to https://github.com/Yaffle/babel-plugin-transform-bigint if they need JSBI support?

Having the source use native BigInt convergent and ages well.

@12wrigja
Copy link
Contributor Author

From that plugin's README:

It will try to detect when an operator is used for bigints, not numbers. This will not work in many cases, so please use JSBI directly only if you know, that the code works only with bigints.

This is type-aware emit, and (from experience rewriting from using big-integer to JSBI) this would be likely too hard for Babel to detect (though easy for tsc to detect, but it's too late at the point this plugin runs).

@Pyrolistical
Copy link

@12wrigja but the neat thing for our use-case is, we only need to verify that babel can detect all the uses in this polyfill specifically and rewrite parts to make it more possible. we do not have the general problem of detecting all possible uses of native BigInt

@12wrigja
Copy link
Contributor Author

verify that babel can detect all the uses

I remain skeptical this can be done correctly.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants