DLL Integration

[shlomiassaf]

@colinskow @abhishekisnot @d3viant0ne @gdi2290

This is my take on DLL integration: Using a plugin to control the whole process.

The plugin internally injects the low level DLL plugins provided by webpack (DllPlugin, DllRegerencePlugin) into the webpack instances.

The plugin handles both the webpack instance it get's registered on and a new webpack instance it creates for bundle generation.

The sole purpose of this plugin is to detect changes to the bundle structure.

Few points:

• The plugin is async (promises). This is for future support of webpack package resolution (currently using node). This is important since webpack can resolve from other directories other then node_module.

• The plugin is ready for live re-bundling. It detects a change in the package level so it can trigger a build per bundle. This will come in handy once live re-bundling is supported.

• No need for extra configuration, everything is in the plugin, no extra commands.
  This makes it super easy to opt-out, just remove the plugin from plugins

If a package is missing the process will throw (using the current config), it will not install from npm or yarn. This is how it should be, the plugin is not responsible for fetching packages, it just bundles the existing.

See source code

Change to the repo is minimal.

PLEASE DO NOT MERGE UNTIL DISCUSSION ENDS

I did not have time for unit tests and proper documentation, I this PR is accepted I will appreciate any help on tests, documentation and adding support to some features.

Thanks.

[colinskow]

@shlomiassaf that's impressive! You took what I did to a higher level. Obviously it's better to handle the DLL build inside a Webpack plugin rather than the npm scripts.

Just a couple small points:

1. Add a clean:dll NPM script, and also add the dll folder to the clean script.
2. You should think about unit testing the logic of your package (outside the Webpack build)

The bottom line is that DLLs make dev builds run a lot faster, once the DLLs are built. This is a good merge as long as it doesn't have unexpected side effects or break existing builds that otherwise work.

[colinskow]

Another idea is to extract the DLL into a separate config file (I used dll.config.js). Since each developer will likely modify this list, this way they can pull updates from the starter with less work.

[PatrickJS]

LGTM

[shlomiassaf]

@colinskow Once the config file is part of the repo it doesn't matter, you have to change the code.

I agree that splitting into a different file has logic to it but I also don't like to many configuration files... so my thought was lets make it super light, nothing fancy and if the user wants a more advanced config he can do it. In 99% of the use cases the common config is sufficient.

The config file for the DLL has nothing to it, it's based on the common... so, IMO, no need to have another config file.

As for unit tests, agreed, but as you can see from my post, I asked for help on that :)

I'll post a clean script later.

[shlomiassaf]

@fxck does this look reasonable for you?

[colinskow]

So we're just missing feedback from @d3viant0ne.

My thinking on separating the config file is that if I want to pull the latest webpack.dev.js from this repo, there are less conflicts to resolve if the DLL config (which most people will customize) is in a separate file. But I'm fine with either way.

[fxck]

I agree that it should be in a separate file, ideally you shouldn't need to touch webpack configs at all, makes updating so much easier. But then again, the whole config should be rewritten in a way similar to this https://github.com/katallaxie/angular2-preboot/blob/master/config/env.ts https://github.com/katallaxie/angular2-preboot/blob/master/webpack.config.ts#L197

[joshwiens]

I agree that making the configs easily extensible would be a definite plus as is limiting the need to touch the webpack configs directly.

Both the preboot & @qdouble's starter do an excellent job of accomplishing this.

[shlomiassaf]

OK, agreed.

Are we going to do it in this PR or we can wait for a refactor for the whole branch?

[shlomiassaf]

I have 3 features I want to implement on the plugin:

• Watch files/package.json for changes and rebuild
• Move package resolution to webpack (now using node require)
• Allow setting the template for file names.

Does anyone want to help?

[shlomiassaf]

Please don't merge yet, might have found a bug.

[joshwiens]

@shlomiassaf - I am personally leaning towards just doing it here if you are up for it. If you don't have the time, I can PR the changes into this branch on your fork and we can land it all at once that way.

Either way it goes, any time we can limit the number of major changes the users have to contend with, the better imo.

[shlomiassaf]

@d3viant0ne I'm not sure I will get to it today so feel free to do whatever :)

BTW, I fixed the bug.

[colinskow]

Looks good to me.

[bmayen]

@shlomiassaf, can you clarify something for me? I've pulled these changes into our build system which is based off of this starter. What I'm seeing is a vendor.dll.js and vendor.bundle.js, both of which contain all of the angular libs. Should there even be a vendor.bundle.js anymore?

[zacharyclaysmith]

Since pulling these changes in, I've just noticed that in prod builds "process" is not defined, whereas it is there in dev builds/runs. Just guessing, but could this be a polyfill compilation/inclusion bug with the webpack.prod.js file stemming from this DLL change?

EDIT: to clarify, I mean that process is not defined in the browser on running the app.

[shlomiassaf]

@bmayen you might see some vendor.bundle but it should be small containing some packages not registered with the plugin.

The way vendors.bundle is configured is that every package that repeats multiple times goes into it so it's easy to forget some...

If all are there you probably have a build with aliasing/moduleDirs that somehow resolves to a non matching resource id

Every resource in webpack gets an id, so alias eventually resolved to the same id as the direct path... this is probably not working for u

[zacharyclaysmith]

Just pulled down the repository fresh and can confirm that somehow the process variable is getting lost along the way with the prod build, filing a separate issue, will link here.

UPDATE: issue #1375

[fryck]

The "DllBundlesPlugin" seems not works properly with "ProvidePlugin".

In my case i want to expose jQuery (because i'm using angular 1.6 with babel) I've tried this :

new ProvidePlugin({
  'window.jQuery': 'jquery',
  jQuery: 'jquery',
  $: 'jquery'
}),

Doesn't work, try with :

{
  test: require.resolve('angular'),
  loader: 'imports-loader?jQuery=jquery'
},
{
  test: require.resolve('jquery'),
  loader: 'expose-loader?jQuery'
}

It works, but it's not very clean, any idea ?

Thanks !

[colinskow]

@fryck try:

externals: {
        // require("jquery") is external and available
        //  on the global var jQuery
        "jquery": "jQuery"
    }

[colinskow]

If this works we should create a Wiki, add this, and remove the deprecated Wikis.