Expected Version Provider Behavior - npm should update package.json, package-lock.json if present, and npm-shrinkwrap.json if present.

[davidlday]

Description

NomProvider currently only updates package.json. However, it is common practice to check both package.json and package-lock.json into git / scm, thus both files should be updated simultaneously.

Possible Solution

Using NpmProvider should by default update both package.json and package-lock.json, with the option of skipping package-lock.json.

Another option would be to have JsonProvider update multiple files using with a unique JSON expression per file. This would allow developers to implement on their own. Configuration could look something like:

[tool.commitizen]
version_provider = "json"
version_files = [
    "package.json:.version",
    "package-lock.json:.version",
    "package-lock.json:.package.''.version"
]

Additional context

See issue #659

Additional context

No response

UPDATED: Fixed the JSON expressions to match what should really be matched.

[davidlday]

After looking through the code for the providers, I came to think the intent was to provide specifics, not abstractions. So, I think adding an npm2 provider solves the specific problem I'm having, which is to update both package.json and package-lock.json. Add a new provider leaves choice intact.

I'll be submitting a PR soon, unless anyone has opinions to discuss.

[woile]

I'd rather have the provider as a separate plugin. We can add it to the third party section

[davidlday]

I checked back wtih NPMs docs to see what the default behavior is for npm version is:

to bump the version and write the new data back to package.json, package-lock.json, and, if present, npm-shrinkwrap.json.

Seems to me, that's what the npm provider should adhere to, but I have no issue creating a new provider that follows this convention.

I'd rather have the provider as a separate plugin. We can add it to the third party section

@woile - just making sure I understood. You'd rather have me add a new provider, i.e. Npm2Provider exposed as npm2, than expose the existing JsonProvider as json, correct?

[davidlday]

I think there should be guidance on implementing version providers. Should they update the same files the native tooling updates? Are there other considerations we should take into account? Version providers are a tremendous boon, imho.

To me, that seems like an obvious yes, but I'll adhere to whatever you all decide. I have this working locally, but haven't pushed changes to my fork yet. I am also considering adding a Maven provider. For me, being able to consistently manage versioning, changelogs, etc across projects (both Open Source and in my day job) via cz is a tremendous time saver. ❤️

[Lee-W]

I'd rather have the provider as a separate plugin. We can add it to the third party section

I belive what @woile said is something like https://commitizen-tools.github.io/commitizen/third-party-commitizen/? But I'm not sure whether we can import a 3rd party provider.

I checked back wtih NPMs docs to see what the default behavior is for npm version is:

If this is something from npm, then I think it makes more sense to update the NpmProvider

[woile]

I checked back wtih NPMs docs to see what the default behavior is for npm version is:

to bump the version and write the new data back to package.json, package-lock.json, and, if present, npm-shrinkwrap.json.

I think we can update the existing NpmProvider with these.

I am also considering adding a Maven provider

That's a great idea, as I said before, version providers are plugins, and we'd like to see the community of commitizen publishing new providers. I'd love to add a section in the docs with all the different providers. I'll try to come up with a template for this

We (as the maintainers of commitizen) don't want to add too many because it's a burden for us to maintain.

A list of other possible providers:

• YarnProvider
• PnpmProvider
• MavenProvider
• MixProvider (Elixir)

[davidlday]

Will leave comments on the PR too, but basically I implemented a new provider believing the changes would break the existing NpmProvider. That's not the case, though. The existing behavior would be preserved. So I'll make the changes to the existing NpmProvider instead of adding a new one.