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
chore: decrease UI build size #43
Conversation
So this creates alternative es modules based pipeline which them can enable better UI optimizations. What if we would switch to |
Trying to switch to es6 gives following scenario, for example, utils-demo (commonjs) depends on market (es6), this results: utils-demo will crash with error: Utils-demo would have to compile differently modules it depends on, which, would also create 2 alternative build pipelines. Ts-node or ts compiler in utils-demo doesn't compile dependencies, so import keywords in dependencies stay as they are, and when utils-demo try to use that dependencies JS code, there's a crash. Switching to es modules where most of our packages are meant to run by node.js could make the pipeline more complicated, because it basically means that we break compatibility with it, unless we would be on higher version of node.js, which I believe is impossible because of our web3 dependency. That said, I'm keen to experiment more and will keep thinking on how to improve our flow. |
Changes:
bundle.js
size from: 8.37 MB to 3.2 MBtsconfig.build.shakeable.json
files which usees2015
modules, so tree-shaking for tools like webpack is possible (commonjs won't work)Issues:
Future ideas: