Warn about Webpack 5 requirement
lostfictions opened this issue · comments
Documentation Is:
- Missing
- Needed
- Confusing
- Not Sure?
Please Explain in Detail...
I generally check changelogs when I'm upgrading dependencies, but a few days ago I tried adding postcss-loader to a greenfield project and couldn't figure out why it wasn't working. I eventually gave up, but today I decided to dig into stacktraces and actually track down what was going on, and after much confusion finally discovered that webpack@4 support was dropped.
Unfortunately, lots of tooling is still stuck on webpack@4. For example, I'm using electron-forge. Most frameworks seem to be approaching the transition carefully -- for example, Next.js announced Webpack 5 support as a backwards-compatible beta but as of now don't appear to have flipped the switch to 5 by default.
Your Proposal for Changes
If you can't keep postcss-loader backwards-compatible, I'd propose to at least make a note in the readme about this change to save other folks some headscratching. It would also be nice to test whether getOptions is defined on this and give a more descriptive error message if so, to prevent more folks suffering from #514. (Happy to make a PR for this.)
If you use npm v7 or yarn PnP or latest yarn you should get error on install step
It would also be nice to test whether getOptions is defined on this and give a more descriptive error message if so, to prevent more folks suffering from #514. (Happy to make a PR for this.)
I don't think extra check (reduce perf) needed here, many developers still not read README and CHANGELOG (trust my experience)
Reading changelog before updating is the best practice...
Thanks for the fast response!
If you use
npmv7 oryarnPnP or latest yarn you should get error on install step
Lots of folks are still on non-PnP yarn, too! And npm v7 will do the wrong thing here -- for my case where I'm using a package that wraps webpack@4, adding postcss-loader@5 will result in two copies of webpack being installed due to its behaviour of installing peerDeps. (Try for yourself: mkdir tmp && cd tmp && npm init -y && npm i -D @electron-forge/plugin-webpack postcss-loader && npm why webpack)
I don't think extra check (reduce perf) needed here, many developers still not read README and CHANGELOG (trust my experience)
I'm proposing a single property access to allow for better debugging/DX -- do you really think this will impact perf that much?
Lots of folks are still on non-PnP yarn, too! And npm v7 will do the wrong thing here -- for my case where I'm using a package that wraps webpack@4, adding postcss-loader@5 will result in two copies of webpack being installed due to its behaviour of installing peerDeps.
And it is right, you need two versions, because other tools require webpack v4 (i.e. no compatibility with v5), please read how peer deps works
I'm proposing a single property access to allow for better debugging/DX -- do you really think this will impact perf that much?
Yep, That is why there is CHANGELOG, otherwise we would have:
if (context.foo) {
context.foo();
} else {
throw new Error('You need webpack v4.5.1');
}
if (context.bat) {
context.bat();
} else {
throw new Error('You need webpack v4.6.1');
}And etc, extra check - reduce perf and readability
Lots of folks are still on non-PnP yarn, too! And npm v7 will do the wrong thing here -- for my case where I'm using a package that wraps webpack@4, adding postcss-loader@5 will result in two copies of webpack being installed due to its behaviour of installing peerDeps.
And it is right, you need two versions, because other tools require
webpackv4 (i.e. no compatibility with v5), please read how peer deps works
Wasn't the point of discussion whether npm v7 will warn of an issue? I just checked -- not only does npm not emit a warning, the toolchain in question (electron-forge) breaks from the automatically-installed peer dep. I'm happy to produce a simple repro if that's helpful, but this is getting away from the scope of the issue a bit.
Wasn't the point of discussion whether npm v7 will warn of an issue? I just checked -- not only does npm not emit a warning, the toolchain in question (electron-forge) breaks from the automatically-installed peer dep.
Just put webpack v5 in package.json
I'm proposing a single property access to allow for better debugging/DX -- do you really think this will impact perf that much?
Yep, That is why there is CHANGELOG, otherwise we would have:
Don't you think this is a bit of a strawman? I'm not suggesting building up warnings and checks for all eternity, but I am suggesting it might be nice to do so on a temporary basis to ease major transitions (and webpack 4 -> 5 definitely isn't trivial for everyone!). I think it's pretty unfortunate that the webpack ecosystem has a widespread reputation for being unfriendly to use, but I don't think that needs to be the case! I like it a lot as a tool and want it to work well and to be approachable for everyone.
There is another problem here - many loader and plugins already require only webpack v5, it will take us time... which unfortunately is not at all due ecosystem has a widespread, I am fine with improve README, but still think extra check is no needed, we really reduce any unnecessary check, but maybe it make sense, anyway my strong recommendation - always read CHANGELOG, complex things can be compared to weapons, if you do not read how to use them, they hit you in the leg
I think that adding a note on the readme about which is the last version that works with webpack 4 is a very little effort that will save much pain to a lot of developers. Your experience may be that many people doesn't read the readme, but I do, and even people that doesn't read the readme will read it after a failure. Expecting that people who doesn't read the readme will read the changelog is even more naive than what is proposed here.
@danielo515 Feel free to send PR to docs
Is correct my assumption that the last version of postcss that works with webpack 4 is postcss-loader: 4.2.0?
Yes, postcss-loader@4 works with webpack v4 and webpack v5
Done #531