Repository navigation
Error after upgrade prevents package.json and yarn.lock from being updated #86
Description
When I try to upgrade a dependency (using yarn upgrade) and I get a new patch failure error from patch-package, I'm left in a weird state where my node_modules do reflect the changes, but my package.json and yarn.lock do not.
My presumption is that the patch-package error stops Yarn from commiting the update to the manifest and lockfile. I'm not sure this is desired behaviour, or whether this is a patch-package problem or a Yarn problem.
Because of the error message, I thought it was safe to go in and re-apply my patch. So I edited node_modules and ran patch-package to generate the new patch, but because the upgrade was not committed, patch-package created a patch of a diff between the version before the upgrade and the version after the upgrade with my changes, which took me awhile to realise.
If we can't fix the bug whereby upgrades are not committed due to the error, we should provide clearer steps in the error message to avoid this.
Activity
OliverJAsh commentedon Dec 13, 2018
I just ran into this again. Any ideas how we can fix this?
ds300 commentedon Dec 13, 2018
Hi 👋 Thanks for the report!
If I understand correctly, it sounds like if
patch-packagereturns > 0 during the'postinstall'or'prepare'hook thenyarntakes that to mean the upgrade failed and won't touchyarn.lockorpackage.jsonbut thenode_modulesfolder still has the upgraded package?That's interesting behaviour! I suppose in that case it is not a good idea for
patch-packageto return > 1 🤔 – It should just be printing an error and hope you notice it. Maybe I could add apatch-package --verifycommand that people can add to their test script so this kind of thing doesn't sneak past CI.OliverJAsh commentedon Dec 13, 2018
Yes, that's correct. I wish that wasn't the behaviour of yarn 😒 Maybe we should file this as a yarn bug.
Failing that we can get this behaviour fixed in yarn, I like your idea.
ds300 commentedon Jan 20, 2019
Hi @OliverJAsh I figured out a pragmatic solution: calling
exit(1)on CI andexit(0)locally. That prevents the confusing upgrade issues while also preventing bad patch files from sneaking past CI, without adding any extra commands. I'll publish a fix for this shortly.ds300 commentedon Jan 20, 2019
OliverJAsh commentedon Jan 21, 2019
Thanks!