Renovate: Failed lock file generation handling (npm/yarn)

[rarkins]

Currently, Renovate skips creating PRs if it cannot successfully create the lock file. Sometimes this is temporary, e.g. the registry is down for a short time, but sometimes this is also "permanent", e.g. the package.json refers to a private package that we don't have authentication for.

For the permanent ones, we want a way to alert the users, but we do not want a huge number of "false" warnings to users every time the registry has a glitch.

The two main approaches we have to alert repository users are:

1. Create an issue (we want to make sure it's limited to one at a time maximum)
2. Create the PR but with a note that the lock file failed

[rarkins]

The idea I have for avoiding temporary problems is to keep ignoring PRs any time there is a dependency update within that is less than a day old. Ideally this should catch most cases where the problem is the registry's and not the config/package.json.

Advantages of raising issues:

• It seems more "logical" that if there is a problem, we raise an issue to describe the problem

Disadvantages of raising issues:

• It would be very hard for us to correctly close them automatically once the problem goes away
• We could include the log file of only the first PR that fails. We wouldn't want to keep piling on top every single other PR's log or the issue could grow very large.

Advantages of raising PRs:

• We can include the actual log for each PR embedded with the PR
• If the problem was temporary after all, the PR can essentially be "healed" and not leave a sign
• If the problem is hard to solve then it still allows users to manually fix the lockfile and merge

[Aghassi]

One thing to note in this is that while the initial onboarding PR doesn't fail, the subsequent one like "pin dependencies" will fail if there is an issue, thus blocking all further PR creation. Ideally, the first Pin Deps PR should be created even if some packages fail. Those packages, should just be skipped and left unpinned while the error is added to the PR. This allows for the rest of the deps to continue updating.

[rarkins]

@Aghassi unfortunately that approach is probably not feasible to implement. Npm/yarn will fail completely, not partially. We’d have to play a guessing game to work out which caused it.

Also, I’m not sure how that’s even happening to you because if a dependency fails to look up at all initially then it won’t be added to the list if dependencies to pin either. I can only see that happening if the failing dependency is an indirect one

[rarkins]

I think though that the special Pin Dependencies PR should always be raised though (with missing lock file and error if necessary).

[rarkins]

This is even more important now that every single configured token has been invalidated by npmjs: https://status.npmjs.org/incidents/dn7c1fgrr7ng

[rarkins]

Alternative idea: raise PRs not issues, but only if all releases are greater than 1 day old. This should prevent most of the “false positives”.

[renovate-bot]

:tada: This issue has been resolved in version 13.21.0 :tada:

The release is available on:

• npm package (@latest dist-tag)
• GitHub release

Your semantic-release bot :package::rocket: