Feature / Integration of DDL for vendor libs

[osdevisnot]

• I'm submitting a ...
  [ ] bug report
  [x] feature request
  [ ] question about the decisions made in the repository

• Do you want to request a feature or report a bug?
  Feature

• What is the current behavior?
  Build Times are high since we are compiling/linking/building all the vendor libs every time we start the application in dev mode.

• What is the expected behavior?
  Build Times can be little lower using separate compilations of vendor libs.

• What is the motivation / use case for changing the behavior?
  We can leverage Webpack's ability to do compiling/linking/building in a separate build step to optimize the build times as outlined here -- http://webpack.github.io/docs/build-performance.html#dynamic-linked-library

• Please tell us about your environment:

• Angular version: 2.0.0-beta.X
• Browser: [all | Chrome XX | Firefox XX | IE XX | Safari XX | Mobile Chrome XX | Android X.X Web Browser | iOS XX Safari | iOS XX UIWebView | iOS XX WKWebView ]

• Other information (e.g. detailed explanation, stacktraces, related issues, suggestions how to fix, links for us to have context, eg. stackoverflow, gitter, etc)
  Related Issues:
  update to rc.5 #843 (comment)
  This feature as implemented in angular-seed -- https://github.com/AngularClass/angular-seed/blob/master/src/dll.ts

[colinskow]

This would definitely be useful for the development build. However, it isn't ideal for the production build since tree shaking doesn't happen.

angular-webpack2-starter has this working perfectly, so it is just a matter of copying the code and specifying the packages we need as DLLs. This will require us to move quite a bit of code out of webpack.common.js since development and production build processes will be different.

[shlomiassaf]

@colinskow We need to be very careful with DLL's.

It's a feature worth having for large scale projects but it will require a big refactor...

We need to figure how how can we do it so people will opt-in and not get it by default...

The other starter with DLL's is super complicated with one huge config that is very hard to understand...

There's a balance...

[joshwiens]

In short, yes we will add DLL support in the future but as stated above we will have to rewrite most of the webpack configs to provide the proper development experience & avoid causing headaches for those who have extended the starter.

IMO if we are going to go through the trouble, we should probably implement it using something like webpack blocks & handle the opt in/out that way.

Regardless of implementation, it's something that really needs to be planned out in advance and then executed to prevent ending up in the weeds.

[fxck]

In short, yes we will add DLL support in the future but as stated above we will have to rewrite most of the webpack configs to provide the proper development experience

Wait what @d3viant0ne? https://github.com/AngularClass/angular2-webpack-starter/tree/v6

I'm honestly confused by this repo. The V6 branch is based on https://github.com/qdouble/angular-webpack2-starter which is at the moment one of the best starters when you want both AOT and DLLs. V6 was more tidy though, cleaned up, a little better file structure, typescript used in configs etc. a pretty good start, and the best thing was that it was using using @ngtools/webpack, so it was less hacky than qdouble's starter. There were couple of issues(#885 (comment)) mostly with @ngtools/webpack, which kinda blocked it, most of them are now resolved though.

So what's the problem with going forward with that branch and finish it? Sometimes I feel like AngularClass's members never talk to each other, let alone to the community when it comes to plans or organization. I'd be more than willing to help finish it, if I at least knew what your plans are, what you feel is wrong with it or whatever, asked twice(#885 (comment) & #885 (comment)) didn't get any answer.

@katallaxie @gdi2290 @shlomiassaf @colinskow

// edit

Found this https://github.com/katallaxie/angular2-preboot which looks like updated version of the V6 branch. So what exactly is the problem here?

[katallaxie]

@fxck yep, the angular2-preboot is the further development of V6. Perhaps, I should update the V6 with some of the things from mine repo, because it is a bit outdated.

[fxck]

@katallaxie what I think you should do is organize effort with the other team members and collaborators(some of which apparently don't even know that branch exits) to get it to master, as it's clearly superior to what's currently on master. Perhaps even create an issue for the community feedback about (env)configs, naming conventions etc. Me having played around with it a bit(even though it was months ago and I'd have to refresh my memory) would probably have couple of things to say.

[colinskow]

Good news, building on @abhishekisnot's pull request I've gotten this working in a way that doesn't require refactor and is highly unlikely to break any existing builds.

The DLL packages must be specified manually in a config file, but anything not included there will simply fall back into the common chunks. I'm even working on a script that will intelligently update the DLLs when a dependent package changes.

This will require testing in the wild to ensure it doesn't break anything, but I think it should be safe to enable by default rather than opt-in, which would complicate things with lots of additional build scripts. The dev build speed benefits are huge.

[osdevisnot]

I'm even working on a script that will intelligently update the DLLs when a dependent package changes.

That sounds even more ambitious than what I was trying to target in my PR . Do you recommend me to look more into this considering you have it covered?

[colinskow]

Done #1341. Let me know if you have any more suggestions @abhishekisnot. And thanks for your help, I did use your code as a starting point.

[joshwiens]

Resolving, DLL support landed in #1358