dependabot only updates lock file

Question

We've recently switched from greenkeeper to dependabot for our dependencies checks and we noticed that dependabot is opening PRs changing only package-lock.json leaving package.json as it was.

On the other hand, greenkeeper, was committing changes to both files.

What is going on? Is it normal or we missed something in the settings?

Rascality

hey @Johnny, did you manage to find an adequate solution to this? – Khanna

@Khanna yes. There's a configuration setting in the dependabot configuration file which forces all updates to be written to package.json also. You should have a look thorough GitHub's dependabot documentation. I might write an answer about it to better explain what to do. – Rascality

I'd love a nice explanation :) The dependabot docs are hit and miss sometimes :) – Khanna

Answer 1

This is a very late reply. We had this working in production for a long time now, but I see there's still interest prompting me that maybe people need some help. So, here it is:

When using GitHub dependabot (not dependabot-preview, although the conf file might be the same, actually):

• create a dependabot.yml file in your repo's .github directory.
• specify a versioning-strategy of increase.

It will look something like this (e.g. npm):

version: 2
updates:
  - package-ecosystem: "npm"
    directory: "/"
    schedule:
      interval: "daily"
    # Always increase the version requirement
    # to match the new version.
    versioning-strategy: increase

That's it. Now, package.json and package-lock.json are both written to with a version increase.

---

Here's the expanded logic behind it. package.json specifies "permanent dependency constraints" on the apps and libraries, while package-lock.json tracks a particular set of exact versions that meet all those constraints, to avoid unnecessary variation. A frequently used constraint type in package.json might be a "caret range" and look like this: ^1.2.3. The caret character is what is making it a range, rather than an exact version specification. Apart from allowing exact versions "1.2.3", it also allows "1.2.9" or "1.4.1", but not "2.0.6"; dependabot can often meet all the caret (and other) ranges in your package.json, while doing the necessary upgrades, without having to change any of these rather liberal constraints. Now, the default versioning-strategy for packages that are considered libraries rather than apps would be widen, i.e., to widen the range as necessary.

Continuing the previous example, if dependabot wants to upgrade a library specified through a caret range as ^1.2.3 (or not constrained at all) from "1.2.3" to "1.4.1", dependabot can leave package.json alone, because "1.4.1" is already allowed by ^1.2.3. However, if it is necessary to make a major upgrade to "2.0.6", then the caret range has to be made wider. It would probably end up replaced by something like >=1.2.3 <=2.0.6 in package.json. If your package.json is very thin (few constraints, liberal constraints), dependabot, when using the default versioning strategy, rarely has to update package.json at all.

But if you change your npm versioning strategy to increase, dependabot will tend to narrow down your caret ranges by increasing their minimums. Instead of ^1.2.3 which stands for >=1.2.3 <2.0.0-0, you could get ^1.4.1 which stands for >=1.4.1 <2.0.0-0 in your package.json.

Apart from the widen (which really stands for "widen if necessary"), and increase (which kind of stands for "always narrow down so as to exclude older versions than our immediate goal"), there's also a value of increase-if-necessary which allows increasing, but only if it is necessary to meet the upgrade goals. If your package.json is very thin (few constraints, liberal constraints), you might not see much difference between widen and increase-if-necessary because dependabot will generally not judge it necessary to interfere with your required ranges.

The lesson for some of us is that we should read up on the package.json syntax possibilities to understand how liberal or specific our existing dependency requirements are, and only then we want to judge dependabot's strategy to their updates, and possibly switch to a different strategy.

Rascality

Can you edit this answer to more clearly say why setting "versioning-strategy" causes the package.json file to update? What about this does that? The documentation from dependabot is not clear. – Firewater

@AndyRay - here you go. – Mendymene

Answer 2

The goal of the file package-lock.json is to keep track of the exact version of every package that is installed so that a product is 100% reproducible in the same way even if packages are updated by their maintainers. reference link is here

So package.json and package-lock.json have different purposes.

There is no error on dependabot trying to push just a modified package-lock.json.

Atom

he didn't ask about an explanation of the difference between .lock and manifest file... – Khanna

This helps me understand a bit better about dependabot's upgrade approach. It would be nicer if there's also a suggestion for package.json, since just upgrading package-lock might break the app. – Hummer

Answer 3

Something similar happened to me, it can be for two things:

1. In the dependendabot configurations you only have to accept updates for package-lock.json
2. (This was the one that worked for me) in the package.json in the key Name you may have written with incorrect symbols in my case I had web-app the symbol - caused me not to update it and now I have it as webapp.

Beguile

Let me understand, probably 99% of the packages on npm have a '-' sign in their name. If that's the problem, this is a big bug in dependabot (probably already found). – Rascality

It's not that, I'm talking about the name of the project in the package.json for example: ` { "name": "ProjectN", => This is what I'm talking about. "version": "1.0.0", "description": "Web App", "main": "index.js" } ` This would be the wrong way "name" : "Project-N" – Beguile