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

web3.js: Remove use of Buffer #1100

Closed
Tracked by #1103
macalinao opened this issue Sep 4, 2022 · 10 comments
Closed
Tracked by #1103

web3.js: Remove use of Buffer #1100

macalinao opened this issue Sep 4, 2022 · 10 comments
Labels
1.x Pertains to the v1.x line on the maintenance/v1.x branch

Comments

@macalinao
Copy link
Contributor

Problem

Buffer isn't built for the web. Uint8Array is and saves 10kb gzipped.

Proposed Solution

Begin migrating code to use Uint8Array instead. Code that doesn't use Borsh should get optimized automatically.

@steveluscher
Copy link
Collaborator

100%. This is another change that we should negotiate with near/borsh-js to eliminate this dependency from the web bundle entirely, everywhere. cc/ @ailisp.

@ailisp
Copy link

ailisp commented Sep 8, 2022

Your treeshaking proposal is impressive! We also have plan to drop Buffer-usage in borsh. Uint8Array is available for all, <10-year browsers. The only challenge part is to borsh serialize a string, it uses Buffer.from(string, 'utf-8'). Standard web api for doing that is TextEncoder, but that need polyfills.

@macalinao
Copy link
Contributor Author

Your treeshaking proposal is impressive! We also have plan to drop Buffer-usage in borsh. Uint8Array is available for all, <10-year browsers. The only challenge part is to borsh serialize a string, it uses Buffer.from(string, 'utf-8'). Standard web api for doing that is TextEncoder, but that need polyfills.

Yeah Uint8Array has good polyfills so I think it's fine-- virtually all frontend packaging tools have some form of browserslist/polyfilling in their build configs.

10kb gzipped if you guys accomplish this. And no more browserify! 🙂

@katopz
Copy link

katopz commented Feb 3, 2023

Glad to hear this! node buffer shim took me almost 3 hours to make it to work for both dev and prod via vite. 🤷‍♂️

@mindrunner
Copy link

Is this already work in progress? I might want to have a look at this. Does anyone know how big/complex this migration gonna be?

@steveluscher
Copy link
Collaborator

My focus is on replacing web3.js altogether. Follow along in #1111 and in all of the new packages in the packages/ directory.

Deprecating Buffer in the current API would probably take just as long as rewriting the whole thing. Backward compat is the hardest thing, because Uint8Array and Buffer behave slightly differently (particularly toString()) and it’s impossible to know who depends on which of the peculiar behaviours.

@val-samonte
Copy link

Sorry for being that guy but any update on this? This prevents me to use vite before.

@buffalojoec
Copy link
Contributor

Sorry for being that guy but any update on this? This prevents me to use vite before.

Unfortunately we can't save the legacy library from Buffer, but the new (2.0) release is going to be all Uint8Array. You can see preview release candidates here:
https://github.com/solana-labs/solana-web3.js/releases

@steveluscher steveluscher added the 1.x Pertains to the v1.x line on the maintenance/v1.x branch label Aug 1, 2024
@steveluscher
Copy link
Collaborator

@solana/web3.js from 2.0 onward is Buffer free.

Copy link
Contributor

Because there has been no activity on this issue for 7 days since it was closed, it has been automatically locked. Please open a new issue if it requires a follow up.

@github-actions github-actions bot locked as resolved and limited conversation to collaborators Oct 29, 2024
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
1.x Pertains to the v1.x line on the maintenance/v1.x branch
Projects
None yet
Development

No branches or pull requests

7 participants