Optimize bundling of Modules/Libs shared between lazy loaded modules

[JohannesRudolph]

Bug Report or Feature Request (mark with an x)

- [ ] bug report -> please search issues before submitting
- [x] feature request

Desired functionality.

Here's a fairly common scenario: I have an application which has two feature modules that each depend on chart.js. Last time I checked with webpack-bundle-analyzer, angular-cli included the full chart.js library in each of the two feature modules.

The more general case is that feature modules (FM) may want to share another module between another, e.g. I have FM A and FM B and both access an angular module X. However, FM C and FM D do not depend on X. It would be awesome if angular-cli could figure that out from the module declarations/imports and then ensure that module X is loaded the first time either FM A or FM B is loaded. Of course, this would require that X be put in its own bundle/chunk.

Mention any other details that might be useful.

I've just stumbled over an article indicating that webpack should support such a scenario with the commonschunk plugin:
https://medium.com/webpack/webpack-bits-getting-the-most-out-of-the-commonschunkplugin-ab389e5f318

[clydin]

The common chunks plugin is actually used. I have also experimented with alternate configurations (various settings, multiple instances, etc.) within the CLI. Unfortunately, the common chunks plugin currently does not analyze the full depth of the child hierarchy. There is this webpack PR that should hopefully improve the situation.

[Meligy]

Unless something like a change to common chunks plugin as above PR etc, it's very hard to bring this in.

Currently (loosely speaking) the only sources for chunks are whether vendor chunk is being used or not, and lazy loaded routes.

For the lazy loading, the compiler checks for the loadChildren routes of AppModule and finds which modules those refer to, and repeats the check recursively for all checked modules. It then generate the route information which is later passed to both Webpack for creating chunks, and the router for knowing which imports to call in runtime. It would require a lot of changes to separate both paths, and to also analyze all imports of each module to decide which is used multiple times and could benefit from being a separate bundle.

Without a separate chunk, the only way to import module X once today is to import it in AppModule. This means it doesn't get lazy loaded, and you get to choose between either lazy loading multiple times, or single initial loading.

[JohannesRudolph]

Hm, I can't comment on the details of integrating this with webpack as I'm far from being an expert in this. Maybe someone like @TheLarkInn could provide some valuable insight as well.

In any case, I though it may be interesting to share the current workaround that I'm using: https://gist.github.com/JohannesRudolph/87bf06aeaa0a94f1129fd0e0216be18f

It's simple and stupid, but at least it ensures very large third party libs (like chart.js) can be reasonably shared between lazy loaded feature modules without duplicate loading. Mind you this comes at the expense of totally evading webpack and any potential benefits we could have from it (e.g. tree-shaking).

[clydin]

The common chunks plugin is already integrated with the CLI. Without additional improvements to the common chunks plugin, there is not much more that can be done currently. Especially if an app has lazy loaded routes with a depth of more than one.

[Meligy]

Have you also considered adding the library to the scripts array in .angular-cli.json, with the lazy option set?

Docs

[filipesilva]

I agree that this is a highly desirable feature. We have to wait for webpack/webpack#4255 for now though.

[lishichao1002]

Rollup not working in async router module #7143

@filipesilva
I update the angular/cli to version 1.2.6. The problem seems to be solved, but it introduces a new problem.
The new problem is the async router module bundle itself twice.

I update the code to the repo angular-asyn-routing-test/tree/dev

Looking forward to your reply.

[mgol]

webpack/webpack#4255 has been resolved, is there another blocker?

[filipesilva]

@mgol I havent had time to look at it further but we've since created a common module that includes all the code shared between lazy routes. Does that not suffice for you case? Can you see any differences when you use the fix in webpack/webpack#4255? If so, you could do a PR.