Allow to suppress warning when used with happypack

[ertrzyiks]

There is a warning, which warns happypack user about lack of support for postcss-loader-before-processing event to prevent potential failure with no clear reason.

Once the problem is acknowledged / resolved on the user side, we may not need that warning in the build output anymore. How could we achieve that?

My ideas:

• introduce an option to explicitly disable postcss-loader-before-processing event
• introduce an option to ignore this particular warning

If you are happy about any of those solutions or know better one, I'm willing to help to make it happen.

[ai]

@jantimon maybe we could remove whole warning? Or make it more smarter?

[jantimon]

Why would a loader have no access to its current compilation?

What about firing the event from the compiler instead?

[ertrzyiks]

@jantimon it is unavailable if you use happypack

[jantimon]

@ertrzyiks why? it is the general purpose intermodule communication protocol and used by many plugins..
what would be the workaround?

[michael-ciniawsky]

@ertrzyiks Is it possible to detect Happypack usage somehow ?

[ai]

Maybe we should remove this warning? Event is very rare and I don’t think warning is very useful.

[ertrzyiks]

I don't know details behind missing _compilation, I can only guess that it was difficult to parallelize it in a reliable way. Maybe @amireh could jump in and share some thoughts.

Having the guard condition enable people to use postcss-loader with happypack. On the other hand, the warning in the else block is just for information and can be removed.

[michael-ciniawsky]

Done #180

[michael-ciniawsky]

But if @amireh could give a insight nevertheless, would be appreciated 😛

[ai]

Released in 1.3.3

[amireh]

The reason is because this._compilation and this._compiler can not be serialized for distributing to other processes since they're constructed and meant to be used in the main webpack process, which is a different "process" than the one that the loaders run in when using happypack.

In the docs for webpack 1 they dubbed it as "hacky access" to these constructs, simply because there was no better way (and I get it that the use cases are usually valid). It's just a limitation we need to live with until webpack (hopefully in v3) starts substituting their use with proper APIs.