It would be nice to have links to each gem's repo and changelog on the https://depfu.com/repos/user/repo page.

Hello.

It'd be nice to see pnpm support (pnpm-lock.yaml lock file).

Depfu seems to be very interesting, however it works only with languages that I (personally) don't use, hence my question: Is there any planned support for languages like Rust, Java or Kotlin?

In the Rust ecosystem you have the cargo package manager that uses a Cargo.tomland a Cargo.lockfile for dependency management.

In the Java/Kotlin ecosystem there are several tools, but I believe one of the most common is Gradle, although in this case the build process doesn't necessarily have a fixed structure.

Even if not these languages specifically I think it would be interesting for users to have an idea of which languages are planned to be supported, or maybe to allow for the community to contribute language support in some way.

Acording semvem (https://semver.org/) the version conventions are:

x.y.z, where:

• x: major
• y: minor
• x: patch

Depfu is calling minor updates as major. Eg: [ruby] Update mysql2: 0.4.10 → 0.5.2 (major)

Depfu marks the version 1.3.0 as insecure, but if I am reading the changelog of it correctly, it seems that version 1.3.0 is still okay.

Is the error on your side or on my understanding?

Screenshot

Github autocomplete suggests to use @depfu[bot]:

But it seems like @depfu[bot] rebase don't work, while @depfu rebase does work. It would be nice that @depfu[bot] rebase also work as it is confusing with the autocomplete. 😉

In the Puppet community it is quite common to find this construct:

source 'https://rubygems.org'

puppet_version = ENV['PUPPET_GEM_VERSION']

gem 'puppet', (puppet_version.nil? ? '~> 6.0' : puppet_version)

Now Depfu cannot know how to correctly handle this. It would be very nice if I could just append the magic comment # depfu:ignore to the line starting with gem 'puppet' and Depfu would instantly know not to send PRs for 'puppet'.

Currently, the depfu bot didn't have a image.
Would be nice to see an image here.

Thank you for building this service 👏 👏

Hello.

I see such information:

I don't understand how "Next pull request" can be in the past (August, there is September now).

No problem or feature request here, just wanted to let you know in case you'd consider this a bug:

Depfu upgraded to beaker-puppet v1.7.0

https://github.com/leoarnold/puppet-cups/pull/66/files

and builds failed because beaker-puppet v1.7.0 depends on beaker ~> 4.1 which was not upgraded. That upgrade was suggested independently

https://github.com/leoarnold/puppet-cups/pull/65/files

but the two PRs were not linked as usual - probably because this project does not use a Gemfile.lock for technical reasons.

It would be great to have repo settings available on the online Depfu dashboard page as configurable values in a config file.

Would need to decide on three things:
1) the location
Can be one location like the root of the project or multiple (fallback) locations, for example inside the .github directory would be nice to avoid an extra 'root' file.

2) the language
Looking at other tools TOML, JS or JSON seem to be the most common. Since JSON is not forgiving on (single) quotes and trailing commas TOML seems to be a good option for Depfu. A great Netlify example documentation page about their TOML config.

3) interaction with dashboard
Either the repo file or the dashboard settings take precedence, the first being the most common in my experience. It would also be great to be able to export settings from the dashboard as config file.

Example config content, including a required version for future flexibility:

version = 1
[strategy]
  outofspec = true
  [strategy.dev-dependencies]
    outofspec = false
[schedule]
  openlimit = 3

My github handle was mentioned in the changelog of next.js. Now I'm being notified and subscribed to all issues opened by your bot for this version, on repositories I have nothing to do with.
Maybe you can just link to the changelogs instead of inlining them, or sanitize them in some way?

Same issue as greenkeeperio/greenkeeper#1113

Depfu.com says

We drip-feed you updates if you're behind, but never open more than 7 PRs at once to not overwhelm you.

I was wondering about the scope of this claim. Is it per day? Per repository? Or maybe per GitHub account, so I might miss out on updates if I don't pay attention those 7 open PRs in that one company repository nobody actually cares about anymore 😉

I am sure you heard that parser gem v2.5.0.4 was yanked from RubyGems.org:

https://stackoverflow.com/q/49499606

The version history of parser now lists this gem as "yanked", but the yanked version was simply missing from the list and "not there at all" in the first days after.

This broke a lot of people's (continuous) deployments.
Protection against such mishaps would be a killer feature in Depfu.

Here's what happend in one of our projects:

1. On Mar 21st Depfu submits "Update rubocop: 0.53.0 → 0.54.0 (minor)":

diff --git a/Gemfile.lock b/Gemfile.lock
index 792335c..6aee8bc 100644
--- a/Gemfile.lock
+++ b/Gemfile.lock
@@ -71,7 +71,7 @@ GEM
     net-ssh (4.2.0)
     netrc (0.11.0)
     parallel (1.12.1)
-    parser (2.5.0.2)
+    parser (2.5.0.4) # <-- This became problematic
       ast (~> 2.4.0)
     powerpack (0.1.1)
     public_suffix (3.0.1)
@@ -94,7 +94,7 @@ GEM
       diff-lcs (>= 1.2.0, < 2.0)
       rspec-support (~> 3.7.0)
     rspec-support (3.7.0)
-    rubocop (0.53.0)
+    rubocop (0.54.0)
       parallel (~> 1.10)
       parser (>= 2.5)
       powerpack (~> 0.1)

2. Around Mar 24th, parser publishes a new sub-patch version - and yanks the version in question
3. On Mar 30th, we deploy - and run into an error

I am not sure why Depfu did not send a PR for the updated parser version (indirect dependency) an whether that is a bug or intentional, but that is also not the point here.

Either way, update to newer or rollback to previous, if Depfu could keep us running despite gems being yanked, that would be awesome!

Please use the comments and emoji reactions to vote on what you need support for.

Right now Depfu supports:

• Ruby (Bundler)
• JavaScript (npm and Yarn)
• Elixir (Hex)

Same as title

I hoped that this could have been a way to postpone some gems from updating :/

Depfu committed as [email protected] which is not registered with the Depfu account, hence Depfu is not showing up as a committer to the repository :-(

See: leoarnold/puppet-cups@b7948e6

Given a Gemfile with only therubyracer included like this one and the corresponding Gemfile.lock.

Currently, the most recent version of therubyracer (0.12.3) depends on libv8 (~> 3.16.14.15).
Actually, therubyracer removed its dependency with version 0.11.0 and reintroduced it with 0.11.1.

However, depfu proposes to major upgrade libv8 to 6.3.292.48.1 by downgrading therubyracer to minor 0.11.0.

Is this intended behaviour?

This is a copy of the PR in our repo. I'll try to reproduce the behavior in a separate repo:

We've updated a dependency and here is what you need to know:

To resolve a dependency conflict, the update changed a few other dependencies as well:

You should probably take a good look at the info here and the test results before merging this pull request, of course.

What changed?

↗️ libv8 (indirect, 3.16.14.19 → 6.3.292.48.1) · Repo · Changelog

✳️ therubyracer (0.12.3 → 0.11.0) · Repo · Changelog

We are trying to make depfu work with one of our private NPM packages. But it seems it's having some problem (or maybe we are missing something).

Current behaviour

1. We release new package to npmjs.com which is privately scoped
2. Depfu has npmjs token to AUTH with that namespace and correctly parses the version change
3. Depfu marks the update as Queued
4. After some time it goes to Waiting state in the dashboard
5. After some time it goes to Running state in the dashboard
6. Nothing happens

Current behaviour 2
Steps 1-2 are same
3. I click manually button Run now in the dependency list
Steps 3-5 are repeated

Current behaviour 3
Steps 1-2 are same
3. I click manually button Create a PR in the dependency list
Steps 3-5 are repeated

Additional findings

• I found out that every npm package has small changelog icon in the list
  
• Our package
  

This leads me to a conclusion that depfu can't in any way communicate with our github repository (as it is private) to parse CHANGELOG.md maybe it even crash because of that ??

The current setup is:

• Private organizational repo for our npm package which is stored on github
• Private npmjs.com scope package
• Access token in depfu (verified as it parses the latest version correctly)
• Our package.json has fields

  "repository": {
    "type": "git",
    "url": "git+https://github.com/toptal/<redacted>.git"
  }

• Our repository is correctly generating CHANGELOG.md on every release, it is correctly creating Release also on GH so it's parsable even by GH API for releases
  

@theflow Any thought on this? Are we missing some magical thing to make it work :)
/cc: @anym0us

If you need more sensitive info feel free to reach me on

TL;DR: There's some bug with Depfu's shields api at https://depfu.com/github/shields/<user>/<repo> that displays some repositories as invalid.

I setup Depfu for my project Blaggy. I wanted to put a depfu badge in my README.md, so I went to Shields.io and entered the correct information. The badge looks like this:

Thinking this might be a problem with Shields.io I checked Depfu's shield API at this URL, but it, too, says "invalid":

The last thing is that the badge on my page at Depfu works properly:

Before you ask me why I can't just use that, it's because I want a style only available (as far as I know) on Shields.io.

This looks a bit strange:

especially since the current release is 8.0.0-beta.27

Depfu has created for us a PR of an update the gem bootstrap. Fine.

The problem comes when we are not interested in update one of its dependencies: autoprefixer-rails. Even if autoprefixer-rails is marked as paused, we can not make Depfu to update the bootstrap gem, without including an autoprefixer-rails update. Am I missing some step, or configuration option?

You can see this in action here: openSUSE/open-build-service#10414

By the way, long term user of Depfu writing here. Awesome job!

Hey,

I've noticed in quite a few projects I work with that use depth that it will create version bump branches even in package.json specifies a caret range and thus the upgrade is covered. It would be great to have a way to turn off this behaviour - perhaps even make it conditional on the presence of lock files.

Thanks.

Let us know any feedback and ideas about our proposal for a new dependencies badge.

Try the new badge quickly by pasting your gemspec in our preview tool.

I really like your grouped update feature for rails. Would it be possible to include rails-i18n if the project uses the gem? Because those Depfu upgrades seem to cause mutual conflicts as of now:

Updaters are what we call the code handling a single file, like a .ruby-version or .circle/config.yml. They know where to find the version and how to update it.

As you can imagine this can be a bit brittle, but in most cases we're quite confident we can make it work well.

We started with a small list of files, so if you're specifying the version of your Ruby/Node.js/Elixir in a file we don't support, we want to know and quickly add support to it.

So far we support

• .ruby-version
• .node-version
• .nvmrc
• .exenv-version
• .tool-versions
• Gemfile and Gemfile.lock
• mix.exs
• package.json
• .circleci/config.yml
• .travis.yml
• Dockerfile
• docker-compose.yml

👉 Please just add a comment for any file that is missing and we'll take a look right away.

When reopening a PR, depfu still keeps it on the closed list

Let's imagine the situation when

1. Depfu [bot] creates a PR to update some dependency.

2. Until the PR gets closed, the same dependency gets updated in base/master branch.
   (I saw case when it was caused by Depfu as well: when another Depfu's PR gets merged).

If versions doesn't match, the conflict occurs.
However @depfu rebase command doesn't help to resolve it.

Desired change:

• Introduce some command to make hard reset on master and re-run package manager's (yarn, npm, etc.) command again.

Here's the real example:

1. Depfu has suggested the following update (and created a PR for this):
   Upgrade eslint-plugin-react: 7.11.1 → 7.12.4 (minor)

2. In the meanwhile eslint-plugin-react has been updated in master to 7.12.0 (I saw the cases when similar updates were caused by Depfu as well)

As a result, package.json and yarn.lock are now conflicting files in the PR.
@depfu rebase doesn't work to resolve it, however the changes are quite obvious.

Few screenshots:

• Changes from Depfu for package.json:

• Changes from Depfu for yarn.lock:

• Conflict with master branch in package.json:

• Conflict with master branch in yarn.lock:

Hey depfu 👋

Wanted to share this idea with you.
E.g. for selected gems like rails, to also submit framework changes that come with an update.

Railsdiff is a great resource to view Rails framework changes. They also provide an API interface. Some version updates are with a lot of changes, but the majority are easy and only touch files that in most cases are not touched by the developer.

• http://railsdiff.org/5.1.3/5.1.4
• http://api.railsdiff.org/v5.1.3/v5.1.4

Hello!

It'll be cool to see Depfu badges in https://shields.io/

But this project need Depfu API for this: badges/shields#1523 (comment)

Thank you.

For example:

• JavaScript (npm) or they would use David.
• Python (PyPI) or they would use Requires.IO.

If Depfu is Ruby-only, it is not as outstanding since there is also Deppbot.

Hey,

thanks for this service!

I registered a repository for a test run and got the first PR but not only the version of the mentioned dependency is changed. The schema part in two URLs of other dependencies was also changed (from https to git) and this causes the tests to fail.

https://github.com/nning/imgshr/pull/2/files

Thanks again and best regards,
henning

Some browser / plugins consider Adobe Typekit a tracker and block the resource. Depfu works perfectly fine without it. You just get this visual glitch:

Hey, I'm RyotaMurakami😀
I'm using Depfu CreateReactApp project and like it!
that infomation(changelog, commit log) is useful written by PR.

Question

I wrote at Fri Jul 20 2018 08:46:37 GMT+0900 (Japan Standard Time)

I have a OSS React Application. https://github.com/ryota-murakami/clock-up
Today i was run yarn outdated command, result is following.

6 package are update available.
But Depfu didn't create PR.

Conclusion, my question is When Depfu create PR?

thnak you made awesome tool😀🎉

For some reason depfu changes the order of entries in the Gemfile.lock, compared to how the local bundler sorts them. The changes are in the GIT section:

-GIT
-  remote: https://github.com/some/gem.git
    ...
 GIT
   remote: https://NOT_GITHUB ...
+GIT
+  remote: https://github.com/some/gem.git
    ...

around a gem from a source other than Github (see above, in the middle, untouched in the diff).

The local bundler sets this source first, while depfu sets it as the last (after the gems from github.com).

The above diff is a result of running the bundle command locally, after a PR by depfu has been merged.

Most of our dependency specifications allow for minor/patch upgrades with no fuss - we just merge those PRs in right away, trusting that it'll be ok based on the maintainers judgement.

However, we want to give a bit more scrutiny to major (breaking) changes. Ideally, we would like all semver compliant upgrades to come in batched every week or so (configurable) while major upgrades each get their own PR that we can analyze ourselves.

When depfu updates linters like rubocop or haml-lint, it is normally the case that the tests fail. 😭 It would be great if there was a way to tell depfu that for some gems it should also run an specific task. I think it is not possible to achieve something like that at the moment. This would completely automatise the process of updating this gems and for sure save many people a lot of time. 😉

I use daily depfu and it's awesome.

To be able to really review the changes being introduced, I would like to have the diff between the gems visible somewhere in the PR, for example as comment in the PR or a link to the diff in my repository dashboard

We know that quite a few teams are using custom docker images as their base image, for example like this

FROM depfu/base:1.0.2-stretch

This makes it basically impossible for us to automatically detect that we need to update that image in the Dockerfile, since there is no relation to the ruby/nodejs version. But it also depends on someone updating the actual image to pull in the new version, so even if we would detect it, there are some workflow dependencies which make this quite tricky.

This is a known issue we're thinking about, but haven't really come up with a good solution yet. if you have any ideas, please let us know!

Take a look at this PR:
https://github.com/marco-carvalho/modal/pull/72

Right now it is trying to update upgrade gatsby from "1.9.279" to "2.29.1". But this is such a big step, that I was wondering if could be possible to create a PR updating to "2.0.0", then to "2.0.1" and so on.

No issue, just FYI: In a Depfu PR today I noticed

while the repository shows

The number of outdated dependencies seems to be accurate but the total dependency surely did not drop by 32 over a rubocop upgrade.

Does one display the total dependency count whereas the other only counts dependencies from the :default group?

One thing I like most about depfu's pull requests is the instant access to the release notes. The Pull Request of grouped updates only gives a link to the changelog 😢

At least that's what I have seen for grouping of dev and indirect dependencies

In my Gemfile I require Bundler to have at least v1.16.0 because previous versions of Bundler ran endlessly, failing to solve the dependency puzzle (heuristics were not good enough to handle dependency monsters like beaker-rspec).

Now Depfu evidently runs on Bundler v1.15.2: leoarnold/puppet-cups#34

What is the recommended way to deal with this? I'd hate to see Depfu suffer the same infinite spinning issues I had.

Are there badges already? If so, can we have your badges integrated with shields.io?

Currently Depfu can't run on multiple branches. It would be nice to be able to enable that Depfu send PRs for security updates in some branches. 🙏

There are already some other services like https://dependabot.com which already support this. 👀

Opening this issues as we have a monorepo that uses Yarn 2 and its constraints feature and encountering compatibility issues with Depfu.

In short, constraints are essentially rules defined in a constraints.pro file at the root of the monorepo, which in our case are enforcing specific versions for certain dependencies throughout all workspaces in the repo. For example, one rule enforces that any workspace using typescript must also use version 3.9.5. We also run the command yarn constraints - which verifies all constraint rules are adhered to - as part of our CI pipeline, to prevent any PRs in violation of the constraints from being merged in.

As you may have already inferred, this becomes a problem as soon as Depfu tries updating any dependency with an associated constrain rule, as the constraint definition becomes "out of date" and the yarn constraints CI check consequently fails.

We have a workaround which is to pause all Depfu updates for the constrained dependencies. However, this necessitates manually managing those dependencies; although not a big deal, it would be much more favourable if Depfu was able to somehow support Yarn 2 constraints.

Perhaps Depfu could modify the version definition in constraints.pro in the same PR as the dependency update? This solution would, however, cause constraint violations if said dependency was only updated in a single workspace opposed to all relevant workspaces.

Being able to instruct Depfu to run yarn constraints --fix might be another potential solution, however, from personal experience that command does not seem very reliable as it doesn't always do anything.

Any thoughts/ideas?

Would be great to get Yarn workspace support, is there any ETA? Depfu is not OS is it? Otherwise I would create a PR.

Hi,

first of all I want to say thank you for this great project

I really love the idea and have already merged a bunch of PRs in one of my open source side-projects (https://github.com/klausmeyer/docker-registry-browser).

I have two short questions:

• Currently I'm waiting for a PR for the upgrade from bootstrap 4.0.0.beta2.1 to 4.0.0.beta3 which is already released a week ago - is anything blocking the update on your side?
• Why is depfu only taking care of gems mentioned in the Gemfile itself and not all of the possible updates? See the following output of bundle update:

diff --git a/Gemfile.lock b/Gemfile.lock
index 53fab5f..205c5fc 100644
--- a/Gemfile.lock
+++ b/Gemfile.lock
@@ -41,10 +41,10 @@ GEM
     addressable (2.5.2)
       public_suffix (>= 2.0.2, < 4.0)
     arel (8.0.0)
-    autoprefixer-rails (7.1.6)
+    autoprefixer-rails (7.2.4)
       execjs
     bindex (0.5.0)
-    bootstrap (4.0.0.beta2.1)
+    bootstrap (4.0.0.beta3)
       autoprefixer-rails (>= 6.0.3)
       popper_js (>= 1.12.3, < 2)
       sass (>= 3.5.2)
@@ -76,7 +76,7 @@ GEM
     faraday_middleware (0.12.2)
       faraday (>= 0.7.4, < 1.0)
     ffi (1.9.18)
-    globalid (0.4.0)
+    globalid (0.4.1)
       activesupport (>= 4.2.0)
     hashdiff (0.3.7)
     i18n (0.9.1)
@@ -96,21 +96,18 @@ GEM
     loofah (2.1.1)
       crass (~> 1.0.2)
       nokogiri (>= 1.5.9)
-    mail (2.6.6)
-      mime-types (>= 1.16, < 4)
+    mail (2.7.0)
+      mini_mime (>= 0.1.1)
     method_source (0.9.0)
-    mime-types (3.1)
-      mime-types-data (~> 3.2015)
-    mime-types-data (3.2016.0521)
     mini_mime (1.0.0)
     mini_portile2 (2.3.0)
-    minitest (5.10.3)
+    minitest (5.11.1)
     multi_json (1.12.2)
     multipart-post (2.0.0)
-    nio4r (2.1.0)
+    nio4r (2.2.0)
     nokogiri (1.8.1)
       mini_portile2 (~> 2.3.0)

In the Web-UI of depfu everything is displayed as "up-to-date".

Best, Klaus

Depfu ran into a conflict trying to apply the security upgrade to Rails 6.0.3.1. By mere fluke I found out that the aged axlsx 3.0.0.pre has a newer drop-in replacement called caxlsx.

Would be nice if Depfu could point that out so projects don't rely on abandoned gems for too long.