fix compilation.compiler not wrapped in callback arguments

[NdYAG]

Hi @stephencookdev

First thanks a lot for this fantastic plugin.!I was searching for a way to measure the performance of webpack building, while the built-in ProfilingPlugin is not that straightforward to measure the timing for each plugin & loader, this plugin shows up and I think it is really brilliant.

One thing though, is that when I integrate it into my project I found that it cannot work with html-webpack-plugin@next. It works with html-webpack-plugin v3 though, but I decided to dig in and take a look. (because I'm also using other plugins that require html-webpack-plugin@next)

So if I do not understand this plugin wrong, it's using proxy and reflect to intercept webpack's tabable plugin system. Object such as compiler and compilation, along with their methods such as tap, tapAsync and hooks are proxyed, which I think is really clever. Even argument in hook's callback is proxyed, such as argument compilation.

The problem lies in how html-webpack-plugin works, https://github.com/jantimon/html-webpack-plugin/blob/master/lib/compiler.js#L203-L218 on apply it will save compiler into a cache weakmap (with the key as the compiler, which is already proxyed). However, in it's thisCompilation hook https://github.com/jantimon/html-webpack-plugin/blob/master/index.js#L134-L136 , it will search that cache again with the key compilation.compiler. ⬅️This is where the problem is from. In SMP, compilation.compiler in hook callback will return the original compiler object, not the proxyed one. I believe this is because in webpack's code, in it's constructor compilation will have a reference of compiler on being created. https://github.com/webpack/webpack/blob/master/lib/Compiler.js#L852-L854 Therefore, if any plugin is accessing compilation.compiler in hooks callback, it will not get the proxied one.

Luckily I found that in your code, you have a wrappedObj which contains the already proxied objects. So it's possible that we check in the wrappedObjs before returning the raw object for compilation.compiler.

I extracted the prevWrapped logic out into a method called findWrappedObj, and reuse it in the proxy handler for property retrieving on argument.

In the issues list I also found that there're some plugins won't work with SMP. I'm not sure if this could help with them. But for html-webpack-plugin@next, you could find how to reproduce it here from this project: https://github.com/NdYAG/smp-html

In this project, before using the patch:	after this patch:

It would be really great if you could take a look of it, if there're any questions please comment and metion me. I love this plugin and hope that it could work with as many other plugins as possible.

[NdYAG]

Debugging screenshots showing that compilation.compiler is not the same in apply and in thisCompilation hook (the proxyed one, and the original one):

[sibelius]

it was breaking for us as well when moving to html webpack plugin v4

[NdYAG]

@sibelius Please try

yarn add https://github.com/NdYAG/speed-measure-webpack-plugin\#fix/compilation-compiler-not-proxyed -D

to see if it works! This branch contains the fix in the PR. I'm expecting more feedbacks.

[stephencookdev]

@NdYAG this looks amazing! I've not had time to debug this issue for ages, so really appreciate the help 🌟

I should have time later tonight (or this weekend at the worst) to check this code out properly and give everything a proper look, and hopefully get this merged 😊

[stephencookdev]

Tested this and it all looks great! Thanks so much, again @NdYAG! I'm gonna get a couple of fixes into a 1.3.2 version, and release that 😄