I did an update to see how much work it would require.
The following packages are not yet compatible with Webpack 3
npm WARN [email protected] requires a peer of webpack@2 but none was installed.
npm WARN [email protected] requires a peer of webpack@^2.2.0 but none was installed.
npm WARN [email protected] requires a peer of webpack@1 || ^2.1.0-beta || ^2.2.0-rc.0 but none was installed.
npm WARN [email protected] 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
extract-text-webpack-plugin
webpack-dev-middleware
webpack-dev-server
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.
@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
well, yarn is still usable on Node 8. And we already test Encore on Node 8
@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.
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:
package-lock.jsonyarn.lock regularly (which is a bit annoying)package.json when it will actually workI'm going to rename this issue to be about updating to Webpack 3, and we can use it to track that.
Thanks!
I created https://github.com/symfony/webpack-encore/issues/39 to discuss the part about improving the testing of different deps on CI
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...)
@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
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
@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.
@DaRamirezSoto please discuss the CI part in #39. Let's keep this issue focused on Webpack 3
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
Most helpful comment
I did an update to see how much work it would require.
The following packages are not yet compatible with Webpack 3
We have to wait for these issues to be resolved before we can properly update to Webpack 3
babel-loader
extract-text-webpack-plugin
webpack-dev-middleware
webpack-dev-server