fix(karma-webpack): Regression in multi-compiler mode (#390)

[jakub-g]

This fixes a regression introduced in [4.0.0-rc4]
See #390 for details

[jsf-clabot]

Thank you for your submission, we really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.

[alexander-akait]

Better avoid using lodash.clone (and lodash.*), they are deprecated and don't updated a lot of time, many of them contain security problems

[jakub-g]

Do you prefer to revert to full lodash then? (or have a better suggestion?)

[alexander-akait]

Better use full lodash (if you use lodash in other places in code) or you can use https://github.com/TehShrike/deepmerge

[matthieu-foucault]

This is the only place lodash would be used.
I am not even sure why we're cloning the webpack config in the first place since it's never been a deep clone, and we're mutating its attributes either way.

[jakub-g]

For info, cloning was added in #48 but as you mentioned, it's a shallow clone, so it in fact does a very poor protection for the original case. I'm thinking to use https://www.npmjs.com/package/clone-deep instead, but this is temporarily blocked until jonschlinkert/shallow-clone#3 is merged and released.

[ryanclark]

Is there any point in cloning the webpack config?

[matthieu-foucault]

We do need to clone the webpack config according to #48.
@jakub-g can you revert to using full lodash then? And use cloneDeep instead of clone

[ryanclark]

If we're fine using Object.assign, can we not just do Array.isArray(obj) ? obj.map((o) => Object.assign({}, o) : Object.assign({}, obj) - instead of introducing all of lodash as a dependency?

[ryanclark]

I mean from what #48 says, I don't think Object.assign is enough (so we should use lodash or deepmerge), but we should try to avoid lodash in it's entirety - I'd pick deepmerge personally

[ryanclark]

If you're adding/removing dependencies, can you commit package-lock.json too please 🙂

[jakub-g]

Hello, I updated the PR (took a while, sorry for that) - can you check again?

For info, the build is failing with webpack_version=next config, but this is unrelated to this PR (it works with webpack_version=latest, and master alredy fails with next)

There's some unwanted diff in package-lock.json probably due to mismatch of npm versions (each version of npm generates a different lockfile, which is quite annoying...)