Feature request: only update yarn.lock or package-lock.json if the version is within range

[StephanBijzitter]

We're going to open source some of our tooling we've been using internally and to provide smaller download sizes (and bundles in case it's meant for the browser), we want to keep the ranges as open as possible for our users, leveraging yarn's deduping.

For example, this means we'd like to keep our package.json at ^1.0.0 for a dependency while our yarn.lock could already lock to 1.2.3.

This will still allow development of the projects to be done with constant updates, without bothering our users. It's not too big of an issue since we can just tell Dependabot to ignore the dependency until the next major release, though.

For us, this would be a bonus; certainly not a requirement.
(we're very happy with Dependabot already)

[StephanBijzitter]

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).

[StephanBijzitter]

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...

[greysteil]

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!)