Update dependencies for webpack 3 (when possible)

[d4r5c0d3]

• Webpack 3
• For usage with next LTS version of node (8); which now include a lock file similar to yarn
• sync additional dependencies ( probably need to wait until some been updated to work with Webpack 3 )

[d4r5c0d3]

I did an update to see how much work it would require.
The following packages are not yet compatible with Webpack 3

npm WARN babel-loader@7.0.0 requires a peer of webpack@2 but none was installed.
npm WARN extract-text-webpack-plugin@2.1.2 requires a peer of webpack@^2.2.0 but none was installed.
npm WARN webpack-dev-middleware@1.10.2 requires a peer of webpack@1 || ^2.1.0-beta || ^2.2.0-rc.0 but none was installed.
npm WARN webpack-dev-server@2.5.0 requires a peer of webpack@^2.2.0 but none was installed.

We have to wait for these issues to be resolved before we can properly update to Webpack 3

babel-loader

• Update webpack to the latest version 🚀 babel/babel-loader#472

extract-text-webpack-plugin

• feat: DeprecationWarning: Chunk.modules in Webpack 3.x webpack-contrib/extract-text-webpack-plugin#529

webpack-dev-middleware

• Add webpack 3 to peerDependencies webpack/webpack-dev-middleware#199

webpack-dev-server

• Add Webpack 3 support webpack/webpack-dev-server#932
• Hot Reloading broke - webpack v3 webpack/webpack-dev-server#949
• Webpack 3 CommonsChunkPlugin.js:289 Cannot read property 'Symbol(Symbol.iterator)' of undefined webpack/webpack-dev-server#947

[stof]

packages-lock.json makes sense only in projects (it has no effect for packages downloaded from npm as dependencies). So nothing forbids you from using npm 5 in your own project when using Encore.

[d4r5c0d3]

@stof
I understand what you mean from a consuming perspective, but I was thinking that since we use npm to run CI via Travis and AppVeyor it would make a difference I might be wrong here though.
This would also mean that we would need to include 8 to testing versions

[stof]

well, yarn is still usable on Node 8. And we already test Encore on Node 8

[d4r5c0d3]

@stof I am missing your point.
Yes yarn is usable on node 8 but what has that to do with adding the package-lock.json so it has proper practise for working with node 8.
Yes we tested encore on node 8 but hole point of CI is to keep testing it automaticly.

[weaverryan]

Hi guys!

Right now we've chosen to use Yarn to manage Encore's dependencies and I don't see a reason to change that right now. And whether we commit a yarn.lock file or a package-lock.json has no effect on our end-users, it's entirely about what we want to use to manage the library. We don't need both.

But, we do need to regularly update the yarn.lock file so that the latest deps are tested on CI.
Unfortunately, this means we're always testing the latest versions of libraries, but not the oldest/lowest versions that are specified in package.json. Composer has --prefer-lowest to help with this, but I don't think yarn/npm has this.

So:

• 👎 for adding package-lock.json
• 👍 for updating yarn.lock regularly (which is a bit annoying)
• 👍 for allowing Webpack 3 in package.json when it will actually work

I'm going to rename this issue to be about updating to Webpack 3, and we can use it to track that.

Thanks!

[stof]

I created #39 to discuss the part about improving the testing of different deps on CI

[stof]

I think more loaders need to be updated for Webpack than the one listed above. We also need to have Webpack 3 support for the optional loaders needing to be installed by users (less, sass, react, vue, etc...)

[d4r5c0d3]

@weaverryan
If Yarn is the chosen manager to develop with should we not use it as well in the CI scripts?
Thank you for renaming this issue to with a appropriate title

[stof]

We use it on Travis (actually, Travis uses it automatically when it sees a yarn.lock file): https://travis-ci.org/symfony/webpack-encore/jobs/244828200#L236

[d4r5c0d3]

@stof Should we change the AppVeyor to work the same way?

Unfortunately, this means we're always testing the latest versions of libraries, but not the oldest/lowest
versions that are specified in package.json

@weaverryan Why would this be an issue? This is how most nodejs packages work.

[stof]

@DaRamirezSoto please discuss the CI part in #39. Let's keep this issue focused on Webpack 3

[weaverryan]

Should we change the AppVeyor to work the same way?

Ah, yes! That was an oversight - it should also use yarn... which can be installed via npm: https://github.com/webpack/webpack/blob/master/appveyor.yml#L24