Let us know if you have any questions or feedback about Depfu by creating an issue.
Get the great feeling of up-to-date dependencies and secure software without all the boring manual work.
π€ Question, bugs and feedback for Depfu
Home Page: https://depfu.com
License: MIT License
Let us know if you have any questions or feedback about Depfu by creating an issue.
Get the great feeling of up-to-date dependencies and secure software without all the boring manual work.
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
npmjs.com
which is privately scopednpmjs
token to AUTH with that namespace and correctly parses the version changeQueued
Waiting
state in the dashboardRunning
state in the dashboardCurrent 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
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 ??
npm
package which is stored on githubnpmjs.com
scope packagedepfu
(verified as it parses the latest version correctly)package.json
has fields "repository": {
"type": "git",
"url": "git+https://github.com/toptal/<redacted>.git"
}
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
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.
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.
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.
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. π
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 π
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.
Hey, I'm RyotaMurakamiπ
I'm using Depfu CreateReactApp project and like it!
that infomation(changelog, commit log) is useful written by PR.
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ππ
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:
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?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
Same as title
I hoped that this could have been a way to postpone some gems from updating :/
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
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.
It would be nice to have links to each gem's repo and changelog on the https://depfu.com/repos/user/repo page.
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:
gem name | version specification | old version | new version |
---|---|---|---|
libv8 | indirect dependency | 3.16.14.19 | 6.3.292.48.1 |
To resolve a dependency conflict, the update changed a few other dependencies as well:
action | gem name | old version | new version |
---|---|---|---|
removed | libv8 | 3.16.14.19 | |
updated | therubyracer | 0.12.3 | 0.11.0 |
You should probably take a good look at the info here and the test results before merging this pull request, of course.
See the full diff on Github. The new version differs by 1 commit:
See the full diff on Github. The new version differs by more commits than we can show here.
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'.
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.
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!
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.toml
and a Cargo.lock
file 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.
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
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
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:
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)
parser
publishes a new sub-patch version - and yanks the version in questionI 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!
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.
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.
Are there badges already? If so, can we have your badges integrated with shields.io?
Acording semvem (https://semver.org/) the version conventions are:
x.y.z, where:
Depfu is calling minor updates as major. Eg: [ruby] Update mysql2: 0.4.10 β 0.5.2 (major)
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
Let's imagine the situation when
Depfu [bot] creates a PR to update some dependency.
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:
Here's the real example:
Depfu has suggested the following update (and created a PR for this):
Upgrade eslint-plugin-react: 7.11.1 β 7.12.4 (minor)
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:
package.json
:yarn.lock
:package.json
:yarn.lock
:Hello.
It'd be nice to see pnpm
support (pnpm-lock.yaml
lock file).
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 :-(
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.
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.
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!
Please use the comments and emoji reactions to vote on what you need support for.
Right now Depfu supports:
When reopening a PR, depfu still keeps it on the closed list
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
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?
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
Would be great to get Yarn workspace support, is there any ETA? Depfu is not OS is it? Otherwise I would create a PR.
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.
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?
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. π
For example:
If Depfu is Ruby-only, it is not as outstanding since there is also Deppbot.
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 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.
A declarative, efficient, and flexible JavaScript library for building user interfaces.
π Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. πππ
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google β€οΈ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.