First bump fails if there are several patters

[fizyk]

It bugged me for a while (few years actually), that when setting up the bump for a project for the first time, the first bump does not catches more complex search patterns.

[bumpversion]
current_version = 0.0.0
commit = True
tag = True
parse = (?P<major>\d+).(?P<minor>\d+).(?P<patch>\d+).?((?P<prerelease>.*))?
serialize =
    {major}.{minor}.{patch}.{prerelease}
    {major}.{minor}.{patch}

[bumpversion:file:package.json]
search = "version": "{current_version}",
replace = "version": "{new_version}",

package json has entry like "version": "0.0.0", inside and other entries like "package": "20.0.0",. Both lines gets their 0.0.0 replaced with "version": "0.0.1", breaking the package.json file in the process.

This is a pretty standard entry with a project we've got also a js piece.

I did a bit of debugging, and what I found was the matching mechanism, and selecting chosen pattern based on the required options. Since by default, the first current version has all pieces default, it does select the longest pattern since it does not finds any required and treats all possible parts as required for the version. This occurs only on the first attempt. Any bump later this would be mitigated by meeting first not-default key-order. bumpversion looks for "version": "0.0.0.0",.

I'll push a pull request that fixes that also prefers the shortest required pattern to cover that case, so in the above case it would look for the actual entry, and replace only the line that matters.

[florisla]

Hi,

Confirmed this is a bug. If current_version and the package.json file match, then this should be found.

However the unit test does not fail on the current (broken) behavior. I think it also has a duplicate name. I'll look into this.

Note that since version 1.0.1, the Json file will no longer be broken. Either it finds the custom search pattern, or it errors out.

VersionNotFoundException: Did not find '"version": "0.0.0",' in file: 'package.json'