You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
While investigating the large bundle size of another project, I noticed the size of near-wallet-selector took up a pretty hefty portion (60 KB gzip), despite only being a wallet-selector modal with separate, composable modules.
In investigating this, I also found that v8.9.11 introduced double the size (122 KB gzip), seemingly because of a near-api-js upgrade/using many modules, @noble in account-export package, and what I'm assuming is poor code splitting.
Some things I've noticed:
We are building for esm and cjs -- why CommonJS if wallet selector is always running in the browser?
Since we're running in the browser, I don't think we need all these polyfills? Should just be using built-ins
I'm not sure if nx w/ rollup is able to shake these shared dependencies out or not... it might not matter... but there are a lot of misc shared dependencies in root package.json which makes installing this project take soooo long and really stresses out my already running-out-of-space laptop (along with this, I think there are several unused dependencies here)
And then some miscellaneous items
main, module, and types are defined in wallet-selector root package.json, despite being non-existant files (I'm assuming this is remnant from before the monorepo)
Duplicate configs in ts and js scattered across the repo
Some wallets are tested, some are not; the tests defined in project root is just the default jest example test
It seems to me like a lot of this is just tech debt that hasn't been addressed from 2 years ago after migrating to a monorepo (and that's okay :) ). Otherwise, I'd really like to learn more about why any of these choices were made, what changes should be implemented, and I'd like to help in any way I can, as well!
Hoping to start a conversation on some of these items -- I feel like the wallet selector is a cornerstone package for the ecosystem and should not bear so much weight on any application integrating it.
The text was updated successfully, but these errors were encountered:
I'm working on something to reduce the size ... excluding everything you mentioned and with which I agree we have few more things to mention ... we have a bg CSS file (~40KB) in modal-ui.
Here is a shot with the changes in next release the size is ~ because we are waiting few more things to be merged but still ;) ...
@near-wallet-selector/core (hopefully next release)
this will help for now ... but still ... there is more space for improvements :)
While investigating the large bundle size of another project, I noticed the size of near-wallet-selector took up a pretty hefty portion (60 KB gzip), despite only being a wallet-selector modal with separate, composable modules.
See version @near-wallet-selector/core#8.9.10 on Bundlephobia
In investigating this, I also found that v8.9.11 introduced double the size (122 KB gzip), seemingly because of a near-api-js upgrade/using many modules,
@noble
in account-export package, and what I'm assuming is poor code splitting.Some things I've noticed:
And then some miscellaneous items
It seems to me like a lot of this is just tech debt that hasn't been addressed from 2 years ago after migrating to a monorepo (and that's okay :) ). Otherwise, I'd really like to learn more about why any of these choices were made, what changes should be implemented, and I'd like to help in any way I can, as well!
Hoping to start a conversation on some of these items -- I feel like the wallet selector is a cornerstone package for the ecosystem and should not bear so much weight on any application integrating it.
The text was updated successfully, but these errors were encountered: