Feature request: only update yarn.lock or package-lock.json if the version is within range about dependabot-core HOT 3 CLOSED

Seems this issue and #178 have a lot in common. I'll close this one (if that's a mistake feel free to re-open it).

from dependabot-core.

Actually, this is probably a bad idea. This means we'll be able to add features added in 1.2.0 yet we still require ^1.0.0, which may resolve to 1.1.0 if another dependency locks it. Ouch, food for thought...

from dependabot-core.

My hunch here is that libraries need something more than just Dependabot, and I'm not 100% sure how Dependabot should fit in.

Off the top of my head, the setup I think a great library should have is:

1. comprehensive build matrix for each major version of its sub-dependencies (realistically this is likely to be one framework-like dependency) which tests again

• the lowest possible sub-version of each major version of the sub-dependency that's supported
• the highest version of the latest major version of the sub-dependency

2. a process to trigger a new test-run each time a new version of a sub-dependency is released

I'm not aware of a solution to (1) for JavaScript - in Ruby it's generally done by not committing a lockfile and using either environment variables in the Gemfile or using a tool like appraisal. I don't think this is something Dependabot can easily help with, at least in the short term.

I think the best way for Dependabot to support (2) is for us to work the same way that Greenkeeper does in the case when a lockfile isn't committed and the README (or some other tell) suggests that the repo is a library. That will require a few changes on our side, but I'm keen to get our library support perfect.

Cross-reference: dependabot/feedback#61.

(And this can stay closed - I'm super aware of this issue and it's covered in a couple of others!)

from dependabot-core.