chore commit type when only the lockfile is updated

[travi]

Which Renovate are you using?

WhiteSource Renovate App

Which platform are you using?

GitHub.com

Have you checked the logs? Don't forget to include them if relevant

No. I think what is happening is probably expected, but i'm hoping it can be configured to behave differently.

What would you like to do?

For a CLI tool, I think it mostly makes sense to pin versions because because it is essentially an "app". However, since it is also published as a package, there are some dependencies that i want to avoid resulting in new versions. for context, i publish using semantic-release, which heavily relies on commit type to determine whether to publish as a major, minor, or patch version. i consider snyk to be in this category since it isn't really a true dependency, but must be installed as a prod dependency to work fully.

I configured one of my projects to prefer updating the lockfile rather than pinning snyk, which seems to have accomplished that piece. However, the lockfile updates still use the fix commit type rather than chore. Since the lockfile is not included when a package is installed, I don't think it is valuable to publish a new version of the package.

Is it possible to configure lockfile-only updates to use the chore commit type, even when the update is for a prod dependency?

[rarkins]

Renovate natively isn't opinionated about semantic commits. Because your preset imports config:base you are inheriting :semanticPrefixFixDepsChoreOthers which is setting those prefixes.

If you augment your config, this should work:

{
  "extends":["github>form8ion/renovate-config"],
  "packageRules": [{
    "packageNames": ["snyk"],
    "rangeStrategy": "update-lockfile",
    "semanticCommitType": "chore"
  }]
}

[travi]

would setting semanticCommitType directly still allow it to use a fix commit type when the version range is bumped to the next major? if i understand the update-lockfile strategy correctly, once a new version is out of range, the package.json would be updated as well. in that case i would not want chore to be used.

[rarkins]

There's a few ways to achieve it, here is one:

{
  "extends":["github>form8ion/renovate-config"],
  "packageRules": [{
    "packageNames": ["snyk"],
    "rangeStrategy": "update-lockfile",
    "semanticCommitType": "chore"
  }, {
    "depTypeList": ["dependencies"],
    "updateTypes": ["major"],
    "semanticCommitType": "fix"
  }]
}

hostRules are always all evaluated, in the order you define them, so the major rule would be applied last and take precedence if there's a major update.

[travi]

this gets pretty close to what i was thinking. the one piece that gives me a little pause is calling out the major updateType explicitly. i called it out above simply because a version that is out-of-range for a dependency range defined with a preceding ^ would be the next major, but the thing i'm really targeting is the fact that it is out-of-range.

is there a more dynamic way to configure lockfile-only updates as chore (since the package consumer does not receive the lockfile update anyway), but updates to the package.json (because the new version was out-of-range) as fix since they are then a change that makes an impact for the package consumer?

[rarkins]

There's no direct way to do it. The rangeStrategy option is an output of packageRules and not an input that can be used to trigger other behavior. The alternative way to do it (but not foolproof) is alongside the original rule and restrict its update types:

{
  "extends":["github>form8ion/renovate-config"],
  "packageRules": [{
    "packageNames": ["snyk"],
    "updateTypes": ["patch", "minor"],
    "rangeStrategy": "update-lockfile",
    "semanticCommitType": "chore"
  }]
}

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed soon if no further activity occurs.

[travi]

sorry for the delay getting back to this. i think your recommendation can get me close enough in this case, but i'm wondering if this is maybe worth a feature request.

i have a hard time thinking of a case where updating only the lockfile should be anything other than chore. it seems like the ideal behavior of the update-lockfile strategy would be chore unless it also updated the package.json (because the update was out of range).

i understand you're saying that there isnt a way to combine that logic today, but would it be possible with minor logic adjustments, or would it be too complex?

[rarkins]

Both commit prefixes as well as lock file updating are implemented in a quite "generic" way so that they can satisfy all languages and styles. Renovate doesn't "really" understand that "only a lock file was updated here so that's less important" because in some package managers the lock file update may be important, or the lock file updating process may trigger an update of the package file too (happens in Go, for example).

The only way I can think to implement this elegantly is if you used our concept of updateType to say "this is not a major or minor or patch update but instead is an in-range update" and you then create a rule based on that, but it's unlikely to be simple.

[travi]

The only way I can think to implement this elegantly is if you used our concept of updateType to say "this is not a major or minor or patch update but instead is an in-range update" and you then create a rule based on that, but it's unlikely to be simple.

interesting. that does at least seem in line with what i'm talking about. i'll ponder a bit and see if i have more thoughts based on that.

as lockfile maintenance PRs are rolling out for the week, that made me at least wonder if there is any part of that process that could apply, but i assume that is pretty distinct from this?

[rarkins]

Lock file maintenance PRs blow away the entire lock file and regenerate it, so it can have potentially dozens or hundreds of updates in one. It does have its own updateType though.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed soon if no further activity occurs.

[rarkins]

Here's the proposal:

Introduce a new updateType called in-range for when the package file remains the same and only lock file is updated.

The problem is, doing it this way may be backwards-incompatible. What if we do this by converting updateType to updateTypes so that it can have multiple values, e.g. ['patch', 'in-range']. Allowing multiple update types could also be the way to solve the breaking feature request too.

[rarkins]

@zharinov could you experiment with what the impact is if we convert updateType (string) to updateTypes (array), leaving all other functionality as-is for now? I know we'd need a small refactor of the updateType matching in packageRules, for example. We also need to make sure that the name conflict with packageRules.updateTypes is ok or if we should name one of them differently.

[travi]

thank you for putting thought into finding a way to make this work.

if i'm following your proposal correctly, you are thinking that this could be used to define the commit-type in a package rule based on whether the update is in-range or out-of-range? something like the following?

{
  "packageRules": [
    {
      "depTypeList": ["dependencies"],
      "updateTypes": ["patch", "in-range"],
      "semanticCommitType": "chore"
    },
    {
      "depTypeList": ["dependencies"],
      "updateTypes": ["patch", "out-of-range"],
      "semanticCommitType": "fix"
    }
  ]
}

also, that would mean that updateTypes is already defined as a list.

am i close to understanding correctly?

[rarkins]

It could be simplified to this:

{
  "packageRules": [
    {
      "depTypeList": ["dependencies"],
      "semanticCommitType": "fix"
    },
    {
      "depTypeList": ["dependencies"],
      "updateTypes": ["in-range"],
      "semanticCommitType": "chore"
    }
  ]
}

i.e. the first rule sets the default that dependencies have a fix type, while the second rule overrides for in-range update types to chore. Currently the semantics for updateTypes in packageRules is "any" matching.

[travi]

got it. this seems very much in line with the goal i was trying to describe, if we can make it work. 👍

[rarkins]

Waiting on #6888

[ITProKyle]

Any progress on implementing the in-range type? Just stumbled upon this issue while trying to configure this exact behavior (for poetry).