Hey, using nexus-core 1.4.0 in signals-app (an EVM-only prediction market on Citrea; source chains are Ethereum/Base/Arbitrum/Optimism/Polygon). Wanted to share a bundle observation and check if there's appetite for a path forward.
When I build, the chunk that contains nexus lands at about 3.7MB raw (974KB gzipped). Looking inside, the bulk is chain client code we don't actually exercise:
@cosmjs/proto-signing + stargate ~300KB
tronweb ~500KB
@starkware-industries crypto utils ~100KB
For EVM-only consumers like us, those ~900KB are dead weight on every bridge modal open. We've actually already had to stub tronweb via a vite alias to suppress some of this. Our code never reaches Universe.TRON.
Was wondering if a per-chain entry would be on the table, in the same spirit as the /core and /ui split from PR #4. Something like:
import { NexusSDK } from '@avail-project/nexus-core/evm';Root entry stays exactly as-is, existing users not affected. Just an opt-in entry for size-sensitive EVM-only consumers.
I know it's not a small refactor given how chain handling threads through core/, services/, and flows/ via the Universe enum. So checking interest first rather than showing up with a PR.
If you'd be open to it, happy to take a stab (was contributor on #184). If the team would rather own this in-house or it's just not a priority, all good.
Hey, using nexus-core 1.4.0 in signals-app (an EVM-only prediction market on Citrea; source chains are Ethereum/Base/Arbitrum/Optimism/Polygon). Wanted to share a bundle observation and check if there's appetite for a path forward.
When I build, the chunk that contains nexus lands at about 3.7MB raw (974KB gzipped). Looking inside, the bulk is chain client code we don't actually exercise:
For EVM-only consumers like us, those ~900KB are dead weight on every bridge modal open. We've actually already had to stub tronweb via a vite alias to suppress some of this. Our code never reaches
Universe.TRON.Was wondering if a per-chain entry would be on the table, in the same spirit as the
/coreand/uisplit from PR #4. Something like:Root entry stays exactly as-is, existing users not affected. Just an opt-in entry for size-sensitive EVM-only consumers.
I know it's not a small refactor given how chain handling threads through
core/,services/, andflows/via theUniverseenum. So checking interest first rather than showing up with a PR.If you'd be open to it, happy to take a stab (was contributor on #184). If the team would rather own this in-house or it's just not a priority, all good.