Closed florisla closed 4 years ago
+1
Hey @florisla I am facing the exact same problem for a package-lock.json
file and am currently bumping that file's version by hand.
Until your PR is merged and included in a release is there any other way to go around this?
Hi, the problem is that the search
expression does not match your package-lock.json
file.
This fix does not solve that problem! Instead of producing erratic output, it will simply not bump the version number.
It looks like one can not use whitespace after a newline in the search
expression (at least when it's defined in an INI-like config file).
I'm not familiar with a workaround; if you put the advanced expression in parse
instead then your current_version
and serialize
need to be mutilated as well. Not fun.
Unless anyone knows a better option, #48 is what you need.
I see. Thank you for the response @florisla
Handling of json files would be absolutely great! Any way I can help pushing that PR? :smile:
@LefterisJP PR #48 needs to be rebased on master and needs some other impovements. Would be great if you could look into it.
This is one of the areas where bump2version does not work like I expect it to.
If for any reason (user error) the
search
pattern is not found, it simply assumes that it can replace{current_version}
with the new version.This can lead to incorrect changes (broken files!) as demonstrated in #126. I often encounter this while developing
search
patterns and when using customreplace
patterns.I think this 'fall-back feature' does more harm than good, and we should drop it.
Given a file version.txt
And a config
Doing
bumpversion patch
produces this without any warning:This is wrong!