Angular-cli: Feature request: separate app and vendor bundles

[neo-sumeet]

Is there any way to have angular cli webpack produce different minified js for third party and app libraries?

1. Running on OSX El Capitan
2. Versions. 6.2.2
3. Repro steps. Created the project with angular-cli: 1.0.0-beta.11-webpack

[kylecordes]

This is a good idea - also I have it listed in my ideas back on #987 which I plan to update once the web pack version ships. Fortunately many of the ideas from that item are already done, I think the one you described here is one of the few remaining to possibly get done in the future.

[TheLarkInn]

We would gladly accept a well written proposal and PR on this feature. It has been highly requested, however not currently at the top of our priority list for the time being.

[filipesilva]

Can you elaborate on what 'different minified js' means? Different how?

[kylecordes]

@filipesilva I think the original poster was asking that the build process emit something like a lib.HASHHERE.min.js file and an app.HASHHERE.min.js file; this is popular among traditional asset pipelines.

Although I wrote above that is a good idea, as I think about it I believe it is also unfortunately incompatible with the tree shaking approach; in theory every application and almost any change to any application will use a very slightly different subset of Angular or other libraries.

We could think of it as a spectrum of optimization:

• On one end, we use off-the-shelf libraries completely unchanged, so utterly vanilla that they can be permanently cached and loaded from CDNs... This minimizes the application JavaScript size (if you don't count for libraries). If those libraries happen to already be in a user's cache, it also optimizes typical JavaScript loading size.
• At the other end, tree shaking of the entire combined application plus all of its libraries. This makes no assumptions about what might already be in a user cache - and therefore, while it minimizes the total code in one sense, it also cannot benefit from any code having already been loaded by other websites into the user's browser in the past.

Angular CLI implements the second thing, not the first thing. My hunch is that this won't change, and this item could be closed as "good idea for some projects for some needs, but sorry not a fit for this project".

[filipesilva]

@kylecordes thank you for explaining. I think I get it now. It hadn't occurred to me how tree shaking would affect this feature, but your considerations are spot on.

There was a point where we had a separate vendor.ts file where vendors were listed to be loaded separately, but we don't have it anymore in master. I think it's worth a discussion for now, so I'll change the title to something easier to understand.

[wulfsberg]

Just pitching in 2 cents here: I suspect one of reasons this has been a highly requested feature is because the System.js dev build hits you with a download of literally a thousand separate files from the different Angular modules. This is a noticeable performance hit while continuously refreshing the page, and the obvious solution would seem to be to pre-package the unchanging angular/vendor modules.

The Webpack version circumvents this entirely with a different build sequence, eliminating this pain point. Without being a mind reader, I'd guess that this really serves the purpose for a pretty large number of the requests for this feature.

[sokolovstas]

This feature is needed for production build to support caching. If we have separate vendor bundle and it didn't change for months we can provide proper caching and speed up application loading. For example my vendor.bundle.js is 4mb, this is maybe not so much but it can save traffic and server loads.

[clydin]

If someone wanted to do this for their project, couldn't they add a vendor.ts file to apps[0].scripts?

[sokolovstas]

Just checked, this is works too, and for now I think this is the best option!

[SanderElias]

@kylecordes @filipesilva Also consider the difference between dev mode and production mode.
During dev, it's ok for me to create 1 large bundle out of all vendor files, and handle all the developers code as a separate bundle. This will will have large impact on performance during development. (My guess, quite a bit faster)

On production one might want to do a complete tree-shake. But as stated above, some might prefer to split it differently as their need is different.

[filipesilva]

We now produce a vendor chunk by default, which can be disabled with --no-vendor-chunk.

[soates]

Is there a way to add libs to this vendor chunk? for example rxjs.

[angular-automatic-lock-bot[bot]]

This issue has been automatically locked due to inactivity.
Please file a new issue if you are encountering a similar or related problem.

Read more about our automatic conversation locking policy.

_{_This action has been performed automatically by a bot._}