Vendor.js is not tree shaked


I just inspected my vendor.js (built with ionic cordova build android --prod) using source-map-explorer and saw that the whole @angular/material module is included.
Even if I never import the whole lib.

I just use the MatDatePickerModule in a lazy loaded page and import it like this in my lazy loaded module:

import {MatDatepickerModule} from "@angular/material";

Here a pic of my vendor.js bundle:

How is it possible that the whole lib is included? Should I open an issue at ionic-app-scripts, or am I doing something wrong?


Solved this by importing the datepicker as follows:

import {MatDatepickerModule} from "@angular/material/datepicker";

But i still think that this is a bug. The compilers dead code removal should detect that I am just importing one module out of like 10+.


Isn’t this identical to your initial post?


I don’t know about this library, but with some, in order to get tree shaking, you need to do a deep import, like '@angular/material/actualPathAndNameOfTheModuleFile'. Don’t know if it would help in this case.


You are right! Copy paste and forgot to edit :confused: I edited my answer
Sorry about that.


Yes this was actually the solution. I am also using date-fns and I’m observing the same issue…So do I really need to import every single function using deep import?

So instead of:
import { addMinutes, addHours, subDays } from 'date-fns';


import { addMinutes } from 'date-fns/add_minutes';
import { addHours} from 'date-fns/add_hours';
import { subDays } from 'date-fns/sub_days';

Of course I could just config this in my IDE, but it’s still not nice to see 15 imports like listed above…


It’s a debate I’m familiar with from discussions of how to design the RxJS library. Deep imports give you better tree shaking, but they are harder to maintain. Move something around a little bit in a new version, and you’ve introduced a breaking change in the code of a lot of developers. So the best situation would be that you import a small module of common commands, and that import path never changes. You almost get tree shaking, and you never have to worry about the import statement again. But each library is going to approach that differently, so I doubt there will ever be a one-size-fits-all solution.