Strategies for Further Tree-Shaking Improvements #665
Description
Is your feature request related to a problem? Please describe.
maxGraph is a fork of mxGraph that didn't support tree-shaking efficiently. Regardless of which parts of mxGraph were used, the contribution to your application size was around 811KB (minified). Since its inception, one of maxGraph’s goals has been to provide better tree-shaking support.
The initial release of maxGraph removed support for Internet Explorer and eliminated custom code that could be replaced by modern ECMAScript APIs. These changes reduced the library size compared to mxGraph.
Additionally, the code was reorganized during the migration—for example, splitting mxUtils object values into multiple namespaces and importing only the necessary functions in applications.
While tree-shaking support has improved since the initial release, further enhancements are needed. The main improvements already available include:
- v0.6.0: Codecs are no longer registered by default.
- v0.11.0:
MaxLogandMaxWindoware no longer called directly within maxGraph, avoiding transitive inclusion. - v0.12.0: The npm package is declared without side effects.
As a result, the contribution of maxGraph 0.15.1 to an application when using default features is around 445 KB minified (the actual value depends on the bundler and its configuration).
The size will be be larger when using Codecs or the Editor class for example.
However, there are still opportunities for improvement. Currently, maxGraph provides many built-in elements that are all loaded by default. While this is convenient for quick evaluations, it is not optimized for production use. For example:
- Applications may not need all shape types.
- Plugins are all loaded by default, even if not required.
- If an application only requires visualization mode (without editing capabilities), the editing-related code should not be loaded.
Derived from the mxGraph implementation, the Graph object remains significantly large. Although it has been broken down into mixins to improve code maintainability, this restructuring has not impacted its runtime size, and unused functionalities continue to be loaded by default.
Describe the solution you'd like
Further tree-shaking improvements that allow selective loading of built-in elements like shapes, plugins, and editing functionalities would enable applications to load only the necessary components, reducing the final bundle size.
A plugin system has been introduced (documentation here), and new plugins will likely be developed to progressively migrate code from the Graph mixins.
Additionally, new global configurations are expected to emerge (documentation here) to better separate concerns and improve modularity.
These ideas have been discussed previously, such as in discussion #8, including concepts like composition over inheritance.
Proofs of concept (POCs) have been identified to address this:
- chore: measure impact of the default configuration on tree-shaking [POC] #432 - Removed default loading of plugins, shapes, edge styles, markers, etc. Result: about 85KB reduction.
- chore: measure impact of the Edge and Vertex Handlers on tree-shaking [POC] #449 - Removed Edge and Vertex Handlers. Result: about 66KB reduction.
- chore: measure impact of the Graph mixins on tree-shaking [poc] #639 - Done on v0.14.0. Converted mixins into optional plugins. Result: about 80KB reduction.
- chore: measure impact of a configurable i18n abstraction over Transactions on tree-shaking [POC] #668 . Done on v0.15.0. Removed usage of Translations and MaxRequest by default. Result: about 5KB reduction.
These POCs were primarily done on version 0.10.3 except if mentioned, before the package was side-effects free, so results may vary slightly with newer versions. However, the outcomes are promising i.e. a potential of around 235KB.
Note
These POC are only an evaluation and the final implementation may differ from that described in these PRs.
Derived from mxGraph, most configurations are global, and these PRs only modify the way in which global configuration is carried out.
It is probably possible to switch to local configurations, but this would require significant internal changes, in particular to inject the configuration into the various places where it is used.
Be aware that switching from global to local configuration is out of the scope of this initiative.
Additional context
This issue will serve as the parent issue for all future work on tree-shaking improvements. Technical solutions and detailed proposals will be tracked through sub-issues.
The repository includes two examples designed to monitor the impact of tree-shaking improvements. These examples measure how much maxGraph contributes to an application's bundle size when none of the built-in elements (which are usually loaded by default) are used—no shapes (except the defaults for vertices and edges), no Perimeters, EdgeStyles, edge Markers, no plugins, and no editing mode.
ts-example-without-defaults: A vanilla TypeScript application built with Vite.js-example-without-defaults: A vanilla JavaScript application built with Webpack.
Important
This is a high-level tracking issue, and comments are locked to keep the focus clear. It serves as an overview of the topic and tracks progress.
For discussions on specific improvements, please refer to the linked sub-issues.
If you'd like to share ideas or feedback, feel free to join the conversation in our GitHub Development Discussions. For user questions or support, head over to the Q&A Discussions.