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.

Sign up for GitHub

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

Jump to bottom

Reduce the Lumos bundle size #516

Open
3 of 6 tasks
homura opened this issue May 17, 2023 · 5 comments · May be fixed by #544
Open
3 of 6 tasks

Reduce the Lumos bundle size #516

homura opened this issue May 17, 2023 · 5 comments · May be fixed by #544

Comments

@homura
Copy link
Collaborator

homura commented May 17, 2023 •
edited
Loading

Background

We've received some feedback from community developers that Lumos is quite large when bundled, which is not friendly for mobile devices

Bundle Analyzer Output

image

stats.json.zip
lumos@487f3235fcfc83409f7752f94962e343684686b5 uncompressed version: 1.7 MB

  • several different versions of bn.js in the bundle, probably due to browserify-crypto and lumos/hd together
  • more than one buffer.js in the bundle
  • cost-effective third-party libraries, such as ludash.isequal

Plan

  • Refactor the require("crypto") to import by demand
  • Unify multiple version dependencies into one version
  • Refactor some oversized third-party libraries with simple functions, such as lodash.isequal
  • Transpile to both ESM and CommonJS, add the module field to point to ESM result
  • Mark the package.json to "sideEffects: false" if it is possible
    • When refactoring, note that @ckb-lumos/config-manager may not be directly marked as "sideEffect: false" since the config.initializeConfig is side-effected
  • Decouple the data structure in the @ckb-lumos/rpc from the axios, allowing developers to choose their own HTTP client if they don't want to use the lumos integrated one
@homura
Copy link
Collaborator Author

homura commented Jun 6, 2023

I encountered some difficulties when refactoring the createCipheriv in @ckb-lumos/hd, because I found that the brwoserify-cipher has a dependency on the browserify-aes, and browserify-aes still has a dependency on the safe-buffer, which may not help reduce the bundle size.

During the exploration, I found that we could refactor with the crypto.subtle, however, most of the subtle API are asynchronous and incompatible with the current lumos synchronous APIs, and we need to evaluate how we should move forward with this part of the work.

@homura
Copy link
Collaborator Author

homura commented Jun 6, 2023 •
edited
Loading

homura#13

@homura homura mentioned this issue Jun 6, 2023
Closed
@homura
Copy link
Collaborator Author

homura commented Jun 7, 2023 •
edited
Loading

image

stats.json.zip
lumos@82b2a9637e95175101dca3361696e26c3e39989e uncompressed version: 1.5 MB

Refactored the require("crypto") to import by demand, reduced about 11.7% bundle size.

This modification also brings more cross-platform benefits to Lumos, so if Lumos needs to be compatible with more JavaScript runtimes in the future, it can be done by implementing the interface in @ckb-lumos/crypto

@homura
Copy link
Collaborator Author

homura commented Jun 8, 2023

image

stats.json.zip

lumos@5c6be0ad2f37373e3293600bc15b2837cd581e1c uncompressed version: 1.31 MB

  • Unified dependencies version
  • remove some unnecessary dependencies, e.g. lodash.isequal

@homura
Copy link
Collaborator Author

homura commented Jun 27, 2023 •
edited
Loading

The ES module can be tracked in this issue #528

@homura homura linked a pull request Jul 24, 2023 that will close this issue
Draft
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

refactor: reduce bundle size homura/lumos
1 participant
@homura