Add webpack 4 support to aspnet-webpack

[mattvperry]

This PR makes aspnet-webpack compatible with webpack 4. I did my best to keep the package backwards compatible. This PR does the following:

1. Move webpack-dev-middleware to peerdependencies.
   • Webpack 4 requires a higher version of webpack-dev-middleware but as far as I can tell, that newer version won't work with Webpack < 4 so in order to maintain backwards compat we need package consumers to choose their version.
2. Use the new hooks API for plugging into webpack
   • I added a check before deciding which API to use for hooking. This should maintain back compat.
3. Some other housekeeping
   • Bumped the dev dependency version of webpack and @types/webpack to 4.5.0 so that aspnet-webpack stays current
   • Change the loadViaWebpack method to remove the ChunksPlugin only if the ChunksPlugin exists. It was removed in webpack 4
   • Change the output encoding of the node services's sub process. The newer version of webpack-dev-middleware was ouputing some unicode characters that weren't displaying correctly. I don't think this will affect anything else but I can take this out if it is a problem.

I did not bump the version of the package because I wasn't sure how you guys wanted to handle that. Support for webpack 4 is crucial for my team since this is the only remaining package causing us to hold off on the upgrade. I would greatly appreciate someone taking a look at this.

[mattvperry]

Should fix #1562

[bharney]

@mattvperry nice! Hopefully this move us one step closer to Webpack 4. I see that there is a conditional for backwards compatibility with CommonsChunkPlugin. And that makes sense because its been deprecated and replaced with the SplitChunksPlugin. Is any configuration needed to get the optimization.splitChunks working?

[mattvperry]

@bharney I don't think so? Mainly because I think that loadFromWebpack function is itself deprecated. I was mainly just making that CommonsChunk change to work around the updated typings

[intellild]

monaco-editor-webpack-plugin relies on webpack 4
is this ready or can we have a beta release, please?😂

[bastienJS]

@mattvperry Any idea why the pull request is not merged yet although the quality gates are green for many weeks now? Can we somehow accelerate that process?

[nikolenkoanton92]

@mkArtakMSFT Can you please take a look?

[jessegavin]

@SteveSanderson any thoughts on this? We would greatly benefit from being able to upgrade to webpack 4.

[chaobidomain]

What is plan for this one? Any dates available?

[bastienJS]

@nikolenkoanton92 as you seem to work for Microsoft. Would you please forward this merge issue to someone having time at Microsoft?

I think a week time to respond is more than enough. Things need to get escalated here. WE the user want that pull request merged finally.

The longer you wait the more merge conflicts you get...

[jessegavin]

If you look at the commit history for the files in the aspnet-webpack section, it seems @SteveSandersonMS has been the primary contributor.

[Havret]

So another abandoned MS project? It sucks as some people actually use it and are willing to spend their own free time to make contribution. :(

[bastienJS]

@jessegavin thus I would say for 4 months this project is dead...

a new toy a new love thats it:
https://github.com/aspnet/Blazor/commits/dev

They are called project hoppers...

[sandcastle]

@natemcmaster / @ryanbrandenburg - any ETA for looking at this? It's a blocker for several projects.

[NathanNZ]

@SteveSandersonMS - would you mind having a look at this PR?

[SteveSandersonMS]

Thanks very much @mattvperry! This looks great. I appreciate your efforts to maintain back-compat with older versions of Webpack. Sorry it took a while to merge.

This is now published to NPM as aspnet-webpack version 3.0.0.