Webpack optimisations - Using DLL

[ngotchac]

By using Webpack DLL optimisation, the rebuild time decreases from 3s to 1 / 1.5s.

It basically build one (could be multiple) file - here vendor - with the commonly used libraries: React, Redux, etc...

Not sure if overkill/necessary...

[parity-cla-bot]

It looks like this contributor signed our Contributor License Agreement. 👍

Many thanks,

Ethcore CLA Bot

[jacogr]

Probably think we should remove 'babel-polyfill' from commons, add it here as well.

[jacogr]

Overall, small comment - however... I'm not sure I like commons + this. Just starts getting messy. What is the time impact if we only have this one and no commons?

I like this approach slightly better. My only concern with this and commons (now that I've had some time) is that for parity.js you actually don't want the common stuff split. That one is meant to be included by 3rd-party devs, not sure I want to force them down the road of including our commons which adds cruft when they only basically want the API.

[ngotchac]

Yes I agree that the two are a bit misleading... So, thanks to the DLL Plugin, webpack doesn't have to rebuild the libraries (such as react, material-ui, etc.) at each rebuild (or event just parse them). This is a huge gain of time.
The CommonsChunk is used in order to separate each parts of the app: when modifying the tokenreg dapp, il only recompile/parse the files of the tokenreg part. This is the most time consuming.

With the two combines, I can achieve a rebuild time of less than 1sec (around 800ms0 for the tokenreg dapp.

For the parity.js file, I added a rule for production build so that it can be used by itself after build.