Igniteui-angular: Enable Tree shaking.

[mshehadeh]

Is your feature request related to a problem? Please describe.

Currently, if i only use IgxGridModule, i end up with the entire ignite UI in my final bundle.

Describe the solution you'd like

I want to be able to import only what i use so i can reduce my bundle size and make my application faster to load. This can be done by adding secondary entry points like angular material, and other components libraries do.

Describe alternatives you've considered

In the docs. i have seen the usage of

import { IgxGridModule } from 'igniteui-angular/grid';
but that does not work anymore.

Additional context

This comes from a starter app where there is nothing except for IgxGridModule imported in app module like below.

`import { IgxGridModule } from 'igniteui-angular';
Once we start adding modules from the components that you provide, this size does not increase or decrease, point towards the entire library being packaged no matter what.

demo-app.zip

I have attached a my-dream-app with where those stats came from.

[kdinev]

Tree Shaking is fully supported on the production build. In order to deliver the build quicker in the dev environment, the angular dev build does not go through the tree shaking, or other optimization procedures. Here's the result of the production build with your sample:

[jorgellose]

I have the same issue with the same example

+921KB in HomeModule, +35 s build time, from 6s to 41s, + 234KB

It is just too much 1.1MB in prod (+365KB basic angular weight, going to 1.5MB with a simple grid), i am seearching the best ui for all the apps we are going to build, visually this library is good but the size is too much.

[mshehadeh]

I don't think this relates to the original issue i raised. The grid is quite heavy, but i think third party grids are generally that size.

This issue relates to the fact that i was reading the data incorrectly + just doing things wrong in general. IGX is tree shaking and tree shaking quite well.

If you think igx is too heavy, maybe raise a new issue.

[jorgellose]

Okay, i thought it was not correct when i saw 250 mentions to Excel in the code, i am not importing than functionality

[kdinev]

@jorgellose I tried a build with and without the grid, and the side of the main module goes up by about ~500kb and styles go up by about ~50kb. The grid itself, however simple it may seem, has dependencies on some of its features, so they can be turned on using a simple input. The grid is the largest component in the library and I would suggest separating components that use it in a separate module, so it can be lazy-loaded.

The 'excel' mentions you're observing are a mix of the excel-style filtering, which is turned on through the filtering configuration, and the excel exporter, which I don't see turned on. We will take a look at whether the exporter service is not being tree-shaken and we can improve that.

[domJalb]

I did some testing with the app provided in the original post and compared bundle sizes on the production build when importing just the grid module vs importing just the button module. The end bundle size is 3.5 Mb (Stat size) regardless of what module you import. It doesn't appear there is any tree shaking going on here, or I'm misunderstanding how to optimize the production bundle.

With GridModule only:

With ButtonModule only:

[mshehadeh]

Hey Dom, you should use source map explorer rather than bundle analyzer as this is the exact same thing that threw me off. Source map explorer considers tree shaking but bundle analyser does not.

---edit---

My statement above is not accurate but its on the same frequency for more info look here and here

[domJalb]

@mshehadeh thank you for that, very helpful.