vendor isn't added to stats.asssetsByChunkName

[faceyspacey]

This would be useful for packages like webpack-flush-chunks which automatically grab assets via the stats.asssetsByChunkName hash.

By default for example it will grab your main and vendor bundles (along with any rendered dynamic bundles/imports it detects), and insure your dynamic bundles go between your bootstrap/vendor and main.

So essentially this saves you from having to add <script src="dist/vendor.dll.js"></script> just in development. One of the premises of the webpack-flush-chunks setup is to help you have as similar a setup in production as development, to make going from development to production as seamless as possible.

It's a small thing, I just thought I'd bring it to your attention. Thanks for this package by the way! Super easy.

[asfktz]

Hi, @faceyspacey!

Really interesting idea you have here.

Sure, if this little change can help AutoDLL better cooperate with your plugin I'll gladly add it.
I have a few critical things on my list first, but I will get to it.

You are more than welcome to send a PR if you like (;

[faceyspacey]

By the way it seems you cant add to stats. I tried but it wouldn't work, and then I come across something that says it's on the Webpack roadmap.

It's unfortunate, but unless I'm missing something, there's nothing we can do.

[asfktz]

Yeah, I'm thinking quite a lot about it lately.

I believe that the reason the stats don't know anything about the DLL is that the plugin creates a separate compiler for the DLL and call it before the main compiler.

What if I give you access to the DLL compiler?

I can expose a plugin hook

compiler.plugin('dll-compiler-created', dllCompiler => {
  dllCompiler.plugin('emit', (compilation, callback) => {
    ...
  });
});

The catch is that I only compile it when needed, otherwise I read the DLL from the cache (file system) so the stats won't be available in that case.

I thought that the stats are not serializable, but then I read in your docs about a plugin called
stats-webpack-plugin maybe I can add this to the DLL compiler config.

What do think?

[faceyspacey]

Regarding the hook, it would need to be 100% reliable. Also currently I'm not passed the compiler, just the stats.

As for the stats, editing the file created by the stats-webpack-plugin would work, but then you would be coupled to that plugin, and users would have to write the stats file even in development, etc. The case of using in-memory-stats wouldn't be solved. So I don't think that route is solid enough either unfortunately.

I think we have no choice, but to wait until Webpack has an API to write to stats.

[codepunkt]

Is there an issue for that or does the webpack team have plans on doing so?

[asfktz]

Hi @faceyspacey!
I added a hook for the DLL stats.

You can use it like this:

compiler.plugin('autodll-stats-retrieved', (stats, source) => {
  console.log(stats)  // stats object
  console.log(source) // build / memory / fs
}

[faceyspacey]

Sweet!

[asfktz]

Let me know if it works for you 😄

[PeterKottas]

Hi @asfktz, I've also encountered a problem of vendor files missing in stats object. I wanted to analyze some issues with size of files it produces but unfortunately it relies on the stats being generated by autodllplugin. Is there any way that could be achieved at the moment? Do you have any suggestions on how to use the hook you mentioned in order to append stats from this plugin to the rest of the plugins?

[asfktz]

HI @PeterKottas!

How about something like this:

class MyPlugin {
    apply(compiler) {
        let dllStats;

        // 'autodll-stats-retrieved' will always be called
        // before the main compiler is done
        compiler.plugin('autodll-stats-retrieved', (_dllStats, source) => {
            // store the dll stats somehow
            dllStats = _dllStats
        })

        compiler.plugin('done', (stats) => {
            // now you have access to both
            console.log(stats, dllStats)
        });
    }
}

[PeterKottas]

Cool, that looks simple enough. I assume this will only output stats specific for the vendors bundle. Or is it actually combining it with the rest of the stats?

[asfktz]

You're right. It's the stats as is.
To be precise, what you get is stats.toJson(),

So if you want to merge them, you might what to do the same for the main compilers stats too:

compiler.plugin('done', (stats) => {
   // now both are serialized
   console.log(stats.json(), dllStats);
});

[PeterKottas]

Nice one! Would it maybe be worth doing that inside autodll-webpack-plugin? Or in fact, if 'done' is called by webpack only after everything is done, I see how that could be a problem. Maybe you could add some prebuild functionality for this? Although it's hard to say how many people are actually interested in this.

[asfktz]

Hmm.. I can see why you want that, other plugin authors might benefit from abstracting away the fact that there's is actually two different stats, but I feel that I'm not familiar enough with the stats to make the merge inside the plugin.

What I can think of is adding another hook right after done that will expose both of the stats, serialized.

compiler.plugin('autodll-done', (stats, dllStats) => {
   // now you have access to both
   console.log(stats, dllStats)
});

[PeterKottas]

I see your point. I would look at it myself but I don't have time for it now (might have some around Christmas). I really believe it would be the best if this could be abstracted away so that we have a switch in options "outputStats": boolean which would just spit out the final merged stats. It's true though that merging stats can be tricky. But maybe not, it might surprise us. If you're fine with it, we can open a new issue or reopen this one and hope to find somebody to help, or at least to keep track.
One thing I struggle with is to understand how many people are actually looking at stats. (Everybody should imho :D, but I doubt that's the case). I normally just check the output for sanity, saves quite a lot of size of js files as there's always some bs forgotten here and there