Setup automatic dependency updates pull-requests

[gaboesquivel]

Keeping your dependencies up to date is a time-consuming and repetitive task, ideal for automation. Luckily there are many tools that help to keep dependencies updated by automatically creating pull requests on your project with the latest versions, your automated tests will run against that pull request and if it passes chances are your code will continue to work normally once you merge it. Be careful with major version changes, always double check.

Greenkeeper.io and david-dm.org are great tools that help to keep dependencies up to date.

[DanielVF]

One of the biggest security issues we face is someone tweaking one of our NPM dependencies to be evil. Because of that we definitely don't want an automatic upgrade system, since the evil could could still pass our tests, but have the evil unlocked in some other way.

Long term, we're going to have to manually review all updates to anything in our dependency tree. That's going to be a pain. In the short term, while in development, only upgrading every once in a while increases the odds that some other project will discover an evil dependency before we do.

[gaboesquivel]

This solution won't automatically update the dependencies, they simply create a pull request that needs to be manually reviewed, accepted and merged by a human being. We can add automatic static security vulnerability scans with

• nodesecurity/eslint-plugin-security for our own code
• nodesecurity/nsp for dependecies.

nodesecurity.io was recently acquired by NPM, so probably soon this will built-in into npm's CLI.

[dobbs]

As I have been trying to get origin & demo-dapp into containers I've been pretty alarmed at the number of dependencies already accumulated in such a young project.

Nevermind someone injecting evil... just keeping up with changes to the upstream code will become unsustainable.

[dobbs]

I don't think you can avoid automating dependency updates.

The more likely risk is not that someone will inject evil code into the project, but that upstream libraries will have easy-to-exploit security holes that don't get caught there and then also don't get updated here.

[gaboesquivel]

I think a lot of dependencies is super common in JavaScript nowadays, it's the micro-package era, similar to Ruby gems, but more extreme, oneliners!
Sindre Sorhus explains it benefits here https://github.com/sindresorhus/ama/issues/10#issuecomment-117766328

I hear you! sometimes you can avoid them by writing native code!

import merge from 'lodash.merge' 
const defaults = {a:1, b:2}
const params = {b:3 }
const options = merge(defaults, params) 
// { a: 1, b: 3 }

// The same result can be accomplished with destructuring

const options2 = { ...defaults, ...params} 
// { a: 1, b: 3 }

Overall I think this static checks for known vulnerabilities are good enough, they pull data from OWASP database. https://github.com/pmd/pmd another good tool to check our own code, not just dependencies.

Analog to the Gemfile.lock file for ruby bundler we have package.lock that will ensure the right versions are installed. This is necessary because there's no guarantee the package maintainers are following semver properly.

The package.lock is the source of thruth no matter if you use caret or tilde in your package.json

~ fixes major and minor numbers. It is used when you're ready to accept bug-fixes in your dependency, but don't want any potentially incompatible changes.

^ fixes the major number only. It is used when you're closely watching your dependencies and are ready to quickly change your code if the minor release will be incompatible.

One downside of automated pull-request for dependency updates is that they can become too many, it could become annoying. Luckily there a way to reduce the PR frequency https://github.com/greenkeeperio/greenkeeper/issues/27. You can define the level of "noise" per dependency by using "^", "~", or pin.

About Docker: Docker is awesome!. It is important to ensure the right node version and node package versions combination are being used at any commit hash in the git log and every environment too. For the front-end stuff live-reload and hot-reload are important, I had problems in the past due to the inotify incompatibilities, I had to use webpack polling https://webpack.js.org/configuration/watch/#watchoptions.
The other day I found this, it looks great https://github.com/gregbkr/geth-truffle-docker.