Closed michaelbull closed 6 years ago
I also would like to see Aurelia building with webpack 4.
Thank you!
I'm aware of this, Webpack 4 introduces breaking changes in its plugin apis.
I am planning to produce a rc.6
compatible with Webpack 4 as soon as I can.
Branch v2.0-rc6
is compatible with Webpack 4.
Known issue: code splitting crashes during build because of external bug, see webpack-contrib/bundle-loader#71
@jods4 That was fast!! should be v3.0 though (-: breaking change
@Alexander-Taran we discussed that internally... technically we never released 2.0.0
, so the only semver rule here is that 2.0.0
RTM contains breaking changes with respect to 1.x
, right?
Would you like a 2.0
compatible with webpack@3
and a 3.0
compatible with webpack@4
? Is there any reason you are not going to update Webpack and can't stay on the rc.5
(which has been RC... well for far too long).
“I’m the serpent king, I can do anything” (-; I’m thinking more of the blind yarn upgrade scenario, whre plugin will be updated but webpack wont
Fair point, pre-release tags are upgraded by ^
and ~
rules, right?
There's a peer dependency on webpack >= 4.0.0
so users would at least get a warning but that's worth reconsidering.
OK good news is that the bundle-loader
problem was fixed in 0.5.6
.
I was tricked by yarn somehow that installed 0.5.5
although my symlinked version requested 0.5.6
, not sure why. Looks like a yarn bug.
Because the plugin is so tightly tied to webpack, why don't you just track the major version of webpack?
webpack
4.x => aurelia-webpack-plugin
4.x
also worth keeping in mind that not the whole webpack ecosystem is up to date. Somwhere someone uses something that is not yet compatible. There absolutely should be a path for those of us who live on bleeding edge, but breaking something for somebody is not good. I doubt that more than 10-20% of developers are keeping up with all the stuff that's coming out. In my opinion clear separation between versions allows for more stable experience.. tonns of package.jsons out there will break up on yarn upgrade.. hours spent trying to figure out why.. less frustration is for the good (-:
It is just an opinion after all (-:
@icanhasjonas also something we're discussing.
The coupling is expressed as a peerDependency
.
It is tempting to align major version numbers but:
4.0
is compatible with Webpack 5.0
? Should we do a blank release just for that?5.0
and the nice alignment is lost. This has potential to create more confusion than it solves.Seeing how other plugins don't do that, we probably won't.
This was closed because we released 3.0.0-rc.1
, which is compatible with (and requires) Webpack 4.
I'm submitting a bug report
Please tell us about your environment:
Operating System: Linux fedora 26
Node Version: 8.9.4
NPM Version: 5.6.0
JSPM OR Webpack AND Version webpack 4.0.0
Browser: all
Language: all
Current behavior: Webpack 4 has been released today. I've upgraded a project and am hitting the following issue when invoking the webpack-cli:
Expected/desired behavior:
What is the expected behavior? The build should run successfully under webpack 4.
What is the motivation / use case for changing the behavior? Compatibility with webpack 4