Detect and separate upgrades from an "unstable" npm version

[fullstackzach]

Which Renovate are you using? CLI, App, or Pro

Self hosted CLI running from a cron job

Which platform are you using? GitHub, GitLab, Bitbucket Azure DevOps

GitLab self-hosted

Renovate pre-set config

  "renovate-config": {
    "default": {
      "extends": [
        ":separateMajorReleases",
        ":ignoreUnstable",
        ":prImmediately",
        ":semanticPrefixFixDepsChoreOthers",
        ":updateNotScheduled",
        ":automergeDisabled",
        ":ignoreModulesAndTests",
        ":maintainLockFilesDisabled",
        ":autodetectPinVersions",
        "group:monorepos",
        "group:recommended",
        "helpers:disableTypesNodeMajor"
      ],
      "description": [
        "Limit to maximum 5 open PRs at any time",
        "Group minor and patch package updates for all deps into one PR"
      ],
      "prConcurrentLimit": 5,
      "labels": [
        "Renovate",
        "Maintenance"
      ],
      "packageRules": [
        {
          "updateTypes": [
            "minor",
            "patch"
          ],
          "groupName": "Minor and patch packages"
        }
      ]
    }
  },

What is your question?

I currently have our patch and minor version packages set to be grouped together into one PR. But, ran into a case where one package (date-fns) had breaking changes between v2-unstable and v2-stable, grouped in with others.

Is there a packageRules config change I can use to separate this situation (moving from unstable to stable) into its own PR so it can be inspected on its own?

[rarkins]

@fullstackzach I've transferred this into the main repo because I don't think we have any way to catch this type of update with today's features.

Today we have an "updateType" field for each update, which is usually major/minor/patch/digest/pin. The case you show would be classified as "minor".

It's a pretty interesting edge case. It's not quite what I'd usually call an "unstable" update because it's going from an unstable to stable. But also the "breaking change" itself is not even because of unstable -> stable. The breaking change is because 2.0.0-alpha.1 came before 2.0.0 and anything x.0.0 can be breaking. So presumably/hopefully it was the update from 2.0.0-alpha.1 -> 2.0.0 where the breaking change was. If the change happened after 2.0.0 then this is just purely a coincidence.

So assuming the breaking change was in 2.0.0 then normally that would be "caught" because updates to x.0.0 are considered major. But in this case it's not considered that because you're already on an alpha release of 2.0.0! One possibility is.. should we consider 2.0.0-alpha.1 to be a "major" update instead of patch? I'm not sure if that's semantically correct. It's a patch update (or even smaller/earlier than patch) but it is still breaking.

One possible way we could handle this is to add a new internal field called isBreakingChange. It would be true for:

• Major updates (e.g. 1.2.0 to 2.0.0)
• Any updates pre-1.0.0 (e.g. 0.0.5 to 0.0.6 or 0.1.0 to 0.2.0)
• Your edge case of 2.0.0-alpha.1 to 2.0.0

Then this field can be exposed to packageRules and your rule would instead be like this:

"packageRules": [
        {
          "isBreaking": false,
          "groupName": "Minor and patch packages"
        }
      ]

[azu]

I have met similar issue.

My understanding(it is wrong) was that ignoreUnstable: true config also ignore updating from unstable version.
But, renovate update to new version from unstable version actually.

I want to control updates that is from unstable version to stable version.

For example, when use the renovate.json, renovate update twillo 3.3.0-edge -> 3.48.0.

azu/renovate-test-ignoreUnstable#2

Actually, this updates includes breaking changes.
Additionally, this update is minor update and renovate(renovate.json) merge the PR automatically.

[viceice]

@azu You really should use some ci checks before automerge, so that it will stop renovate from merging incompatible packages.

[azu]

@viceice Yes, CI check the updates.
But, test coverge 100% is hard.

I want to update unstable versions manually.

Current workaround ignore the package by packageNames.

[rarkins]

Renovate should update unstable -> unstable only if they share the same major.minor.patch.

I think this feature would benefit from us having the concept of "isBreaking" so that you can disable automerge for all breaking, including both major or unstable like this.

[azu]

OK. isBreaking looks good to me.

My understanding is following:

• unstable changes:
  • stable version → pre-release version: 1.0.0 → 1.1.0-beta.1
  • pre-release version to new pre-release version: 1.0.0-beta.1 → 1.1.0-beta.2
• breaking changes:
  • pre-release version → stable version: 1.1.0-beta.1 → 1.2.0
  • major updates: 1.0.0 → 2.0.0
  • 0.y.z updates: : 0.1.0 → 0.2.0