search

aurelia / webpack-plugin

A plugin for webpack that enables bundling Aurelia applications.
MIT License
90 stars 36 forks source link

Compatibility with webpack 4 #138

Closed michaelbull closed 6 years ago

michaelbull commented 6 years ago

I'm submitting a bug report

Please tell us about your environment:

Current behavior: Webpack 4 has been released today. I've upgraded a project and am hitting the following issue when invoking the webpack-cli:

> webpack --env=production

[...]/node_modules/aurelia-webpack-plugin/dist/ModuleDependenciesPlugin.js:36
            const resolve = compiler.resolvers.normal.resolve.bind(compiler.resolvers.normal, null, this.root);
                                                              ^

TypeError: Cannot read property 'bind' of undefined
    at compiler.plugin ([...]/node_modules/aurelia-webpack-plugin/dist/ModuleDependenciesPlugin.js:36:63)
    at AsyncSeriesHook.eval [as callAsync] (eval at create ([...]/node_modules/webpack/node_modules/tapable/lib/HookCodeFactory.js:24:12), <anonymous>:7:1)
    at AsyncSeriesHook.lazyCompileHook [as _callAsync]

Expected/desired behavior:

nathanchase commented 6 years ago

I also would like to see Aurelia building with webpack 4.

Thank you!

jods4 commented 6 years ago

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.

jods4 commented 6 years ago

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

Alexander-Taran commented 6 years ago

@jods4 That was fast!! should be v3.0 though (-: breaking change

jods4 commented 6 years ago

@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).

Alexander-Taran commented 6 years ago

“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

jods4 commented 6 years ago

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.

jods4 commented 6 years ago

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.

icanhasjonas commented 6 years ago

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

Alexander-Taran commented 6 years ago

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 (-:

jods4 commented 6 years ago

@icanhasjonas also something we're discussing. The coupling is expressed as a peerDependency. It is tempting to align major version numbers but:

Seeing how other plugins don't do that, we probably won't.

icanhasjonas commented 6 years ago
jods4 commented 6 years ago

This was closed because we released 3.0.0-rc.1, which is compatible with (and requires) Webpack 4.