dependabot / dependabot-core

🤖 Dependabot's core logic for creating update PRs.
https://docs.github.com/en/code-security/dependabot
MIT License
4.72k stars 1.02k forks source link

Major version update for caret version (^3.6.1 suggests 5.1.0) #1779

Closed theNailz closed 2 years ago

theNailz commented 4 years ago

We're using dependabot in a javascript project. Today we got a pull request from Dependabot to upgrade a lib to a new major version, while our package.json defines the version ^3.6.1, which should mean not to change the most left digit.

.dependabot/config.yml:

version: 1
update_configs:
  - package_manager: "javascript"
    directory: "/applications/webapp"
    update_schedule: "weekly"
    target_branch: develop
    default_labels:
      - "dependencies"

package.json:

// devDependencies:
"fuse.js": "^3.6.1",

Corresponding log from Dependabot:

updater | INFO <job_28821646> Checking if fuse.js 3.6.1 needs updating
  proxy | 2020/04/06 09:04:17 GET https://registry.npmjs.org:443/fuse.js
  proxy | 2020/04/06 09:04:17 200 https://registry.npmjs.org:443/fuse.js
  proxy | 2020/04/06 09:04:18 GET https://registry.npmjs.org:443/fuse.js/5.1.0
  proxy | 2020/04/06 09:04:18 200 https://registry.npmjs.org:443/fuse.js/5.1.0
updater | INFO <job_28821646> Latest version is 5.1.0
  proxy | 2020/04/06 09:04:19 GET https://registry.yarnpkg.com:443/fuse.js
  proxy | 2020/04/06 09:04:19 200 https://registry.yarnpkg.com:443/fuse.js

Is this a bug in Dependabot?

dev-zero commented 4 years ago

it seems that dependabot has a general issue with the caret: in my Python project I have ^0.8 which allows versions >= 0.8.0 && <1, nevertheless, I get a PR with the requested change:

-pygls = {version = "^0.8", optional = true}
+pygls = {version = ">=0.8,<0.10", optional = true}

to allow pygls-0.9, see https://github.com/cp2k/cp2k-input-tools/pull/12

justinlang commented 4 years ago

I believe we are experiencing this issue as well.

We have in our package.json: "graphql": "^14.7.0", But dependabot is opening a PR to change this to: "graphql": "^15.3.0",

Not sure how to find dependabot logs but would be happy to attach them if someone can tell me where they are.

dev-zero commented 4 years ago

I believe we are experiencing this issue as well.

We have in our package.json: "graphql": "^14.7.0", But dependabot is opening a PR to change this to: "graphql": "^15.3.0",

Not sure how to find dependabot logs but would be happy to attach them if someone can tell me where they are.

Maybe I am wrong, but I would see that as intended behavior: the "caret" usually acts on the last segment, meaning that ^14.7.0 is equivalent to >=14.7.0 && < 14.8, right? Hence the PR to upgrade the requirements to a new range.

justinlang commented 4 years ago

I believe ^14.7.0 is equivalent to >=14.7.0 <15.0.0. https://classic.yarnpkg.com/en/docs/dependency-versions/#toc-caret-ranges

I could be fundamentally misunderstanding what dependabot is supposed to be doing. I thought that it evaluated whether a project could be updated to a newer version of a dependency based on the version constraint. I don't quite understand why it's opening a PR and completely changing the version constraint. Apologies if I've hijacked this issue.

justinlang commented 4 years ago

Apologies, I think what I'm observing is not related to this issue and is intended behaviour. See https://dependabot.com/blog/ignoring-major-version-bumps/:

Previously, Dependabot would troll you every time a new 4.x release came out. We liked to call it reminding, but let's be honest. Specifying a version constraint in your package.json wouldn't help either - Dependabot would just bump that constraint for you, too.

Cheers!

jurre commented 4 years ago

You can configure the desired behavior: https://docs.github.com/en/free-pro-team@latest/github/administering-a-repository/configuration-options-for-dependency-updates#versioning-strategy by default Dependabot will update to the latest version available. I think lockfile-only is what you'd want to configure for this

jurre commented 2 years ago

I think this can be resolved by adding the suggested configuration, so I'm going to close this issue out.