workbox-build@6.2.0 not compatible with workbox-webpack-plugin@6.0.2
See original GitHub issueLibrary Affected: workbox-webpack-plugin
Browser & Platform: n/a
Issue or Feature Request Description:
After 6.2.0 was published yesterday, our project that is constrained to workbox-webpack-plugin: ~6.0.2 started failing with zero changes to our code base. It appears the constraint in this package workbox-build: ^6.0.2 causes an upgrade to 6.2.0, which does not appear to be backward compatible with 6.0.2 of the plugin.
Error: Cannot find module 'workbox-build/build/options/schema/webpack-generate-sw'
Our workaround for now is to fix workbox-build back to 6.0.2 using resolution fixing:
"resolutions": {
"workbox-build": "~6.0.2"
}
We’ve put out the fire on our end, but I can imagine anyone else using conservative constraints like our project will also run into build failures after yesterday’s release. Please let me know if you have any questions or need additional detail.
Issue Analytics
- State:
- Created 2 years ago
- Reactions:7
- Comments:8 (6 by maintainers)

Top Related StackOverflow Question
Okay, release v6.2.2 uses the
--exactflag, so we should hopefully not run into the same issue in the future.I’ll leave this issue open to evaluate the impact on developers who are stuck for some reason on a mismatched older version of the Workbox libraries.
Gotcha. I’ve filed https://github.com/GoogleChrome/workbox/pull/2906 and I’m going to give that change a try soon with a pre-release publish to
npm, as it’s really hard to test the actuallernaflow without doing a publish. Assuming that looks as expected, I’ll flag it aslatestonnpm.I don’t think that change is going to address the 6.0.2 vs. 6.2.0 compatibility issue retroactively, because 6.2.0 was written with the assumption that all of the mutual dependencies would also use 6.2.0, and it’s not going to be trivial to undo that. But moving forward, for 6.2.1 on, I hope that our dependencies will accurately reflect that intention.