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

Use dynamic import for mxgraph to reduce final main bundle size #19

wants to merge 2 commits into
base: master


Copy link

commented Jun 5, 2018

Thanks for the work!

@SylvainCorlay and I talked about some ways to make this extension more adoptable, and a big one is getting the end-user build burden under control... all it takes is a few big dependencies, and end users will start running into out of memory errors for production builds.

This PR uses a dynamic import().then((mx)=>...) for mxgraph which moves the vendored code into its own separate bundle, enabled by a tweak to tsconfig.json and some changes to editor.ts.

While it still imports ./mxgraph/.../modulated.js for typing, this doesn't trigger bundling into main, and a new promise handles some housekeeping until the extra bundle loads. The net effect is a lot less spinning moons up-front and a lot more spinner the first time you create a drawio editor, but this seems like a reasonable trade.


jupyter lab build before dynamic loading:

Time: 48291ms
                                 Asset       Size  Chunks                    Chunk Names
             0.279ec850a9242db04c85.js     465 kB       0  [emitted]  [big]  
          main.61b90d338d4f30708998.js    3.82 MB       1  [emitted]  [big]  main
        vendor.dc51f756bf07759c9f87.js    1.57 MB       2  [emitted]  [big]  vendor
      manifest.a4f4df6bc82fcc2452d4.js    1.62 kB       3  [emitted]         manifest    1.35 MB       0  [emitted]          14.6 MB       1  [emitted]         main    5.69 MB       2  [emitted]         vendor    8.24 kB       3  [emitted]         manifest

jupyter lab build after dynamic loading:

Time: 41686ms
                                 Asset       Size  Chunks                    Chunk Names
             0.279ec850a9242db04c85.js     465 kB       0  [emitted]  [big]  
             1.1744eaa7d53b3aae4ebe.js    1.51 MB       1  [emitted]  [big]  mxgraph
          main.395f70c2ada21ac40f18.js    2.31 MB       2  [emitted]  [big]  main
        vendor.a77cf169b5927fb4a051.js    1.57 MB       3  [emitted]  [big]  vendor
      manifest.b77db697007c7c420aa4.js    1.65 kB       4  [emitted]         manifest    1.35 MB       0  [emitted]             5.41 MB       1  [emitted]         mxgraph    9.16 MB       2  [emitted]         main    5.69 MB       3  [emitted]         vendor    8.29 kB       4  [emitted]         manifest

The slightly shorter build time could be incidental, but the size difference is pretty real...

Also, since i was doing a bunch of builds, I snuck in the spdx-compatible license string because i got tired of the warnings.

The other thing to making this more adoptable (out of scope for this PR) is some strategy for removing the runtime dependency. Not sure the right way to do it: one could make an nbextension, and pack all that stuff in there, but that feels really dirty. I am figuring we'll end up needing a predictable, runtime-addressable spot to put statics, especially for wasm and complicated existing apps like this-a-here one.

Thanks again!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
None yet
1 participant
You can’t perform that action at this time.