Tree Shaking optimizes bundles that use ES6 modules (see descriptions at webpack.js.org and rollupjs.org). DevExtreme is available as a set of CommonJS modules and cannot be optimized in this way.
We also have multiple reported issues related to CommonJS modules, Tree Shaking, and large bundle size:
In addition, Angular recommends using ES6 modules in your entire application.
To deliver a set of ES6 modules in addition to CommonJS modules. This step solves all the described problems while providing backward compatibility. It also makes future enhancements like Improved Code Splitting more efficient.
No changes in your projects are required. The new ES6 modules will be used instead of the old CommonJS modules automatically.
Do you find Tree Shaking useful?
Have you tried using multiple bundles in any of your projects (e.g. a bundle per page)?
Subscribe to this thread, or to our Facebook and Twitter accounts, for updates on this topic.
This amazing feature will be available in next 20.2 official release? 馃帀
That's right.
I think it will be available for testing a bit earlier - let's say, in 20.2 Beta. If so, I will post an update in this thread.
That's awesome! Any Eta updates?
Sounds great.
@IlyaKhD When do you think we can try this out in an alpha-build?
Hi,
Our work on this feature is at the final stage. We will update this topic once we publish an NPM package with it.
@MaximKudriavtsev is it part of the 20.2.2-beta?
Hi @BoBiene,
Unfortunately no, the Beta version doesn't include ES6 modules. We have some unexpected implementation issues, and now we are fixing them.
We would like to publish one more Beta version with this feature before the official release. I will notify you once we do so.
Does it means if this are finished, tools like Vite Scafford for Vue3 also be supported? Vite also depends on ES6 modules.
Unfortunately, Vite requires that all packages have ES6 modules. DevExtreme depends on jszip which provides CommonJS modules only.
Hi
https://github.com/Stuk/jszip/issues/349, it supports es6 import
@softboy99 the problem with jszip is not with the way you import it but how the library itself is structured. It's a CommonJS module.
Hi,
https://www.npmjs.com/package/@progress/jszip-esm. It is forked by telerik
Hi everyone,
We'd like to make an update on ES6 modules support.
The good news is that we've finished all the major tasks related to this feature. However, when we tested our new module set with some of the existing DevExtreme projects, we faced unexpected issues that might break our customers' projects. So, we consider it to be too risky to make it part of our stable v20.2 release.
Since it's very important to let you test these new modules in your projects, we plan to include them in the very first v21.1 alpha release that we expect to publish in a few weeks.
The next step in our bundle size optimization journey is to organize DevExtreme into smaller modules. For instance, to split our DataGrid into multiple parts based on different use cases. It will enhance the overall tree shaking and code splitting. We would also appreciate it if you share your cases when unused/unexpected code is bundled while it shouldn't. It'll help us improve the most important parts first.
Please stay tuned and thank you for your collaboration.
So the only solution so far to avoid these warnings is "allowedCommonJsDependencies"??
@javzwin until ES6 modules are released, yes, it is.
Does this 21.1 Branch supports es6 import..?
Hi, @mrparag94, sorry for the late response.
I'm not sure you mean that, but you can use ES6 import statements with all actual DevExtreme versions, e.g., v20.2.
About the 21_1 branch, we're reorganizing the package structure, which is important for bundle optimization.
When is the release of 21.1 planned?
@Rai-Rai the major DX releases usually come in 6 months intervals, so I would guess May 2021.
Do you have plans for moving devexpress-diagram, devexpress-gantt, devextreme-quill to optionalDependencies? Or just remove from dependencies
Most helpful comment
Hi everyone,
We'd like to make an update on ES6 modules support.
The good news is that we've finished all the major tasks related to this feature. However, when we tested our new module set with some of the existing DevExtreme projects, we faced unexpected issues that might break our customers' projects. So, we consider it to be too risky to make it part of our stable v20.2 release.
Since it's very important to let you test these new modules in your projects, we plan to include them in the very first v21.1 alpha release that we expect to publish in a few weeks.
The next step in our bundle size optimization journey is to organize DevExtreme into smaller modules. For instance, to split our DataGrid into multiple parts based on different use cases. It will enhance the overall tree shaking and code splitting. We would also appreciate it if you share your cases when unused/unexpected code is bundled while it shouldn't. It'll help us improve the most important parts first.
Please stay tuned and thank you for your collaboration.