Update dependencies to enable Greenkeeper 🌴

[greenkeeper]

Let’s get started with automated dependency management for bonde-client 💪

⚠️ We found a yarn.lock file in this repository. You need to use greenkeeper-lockfile to make sure it gets updated as well.

This pull request updates all your dependencies to their latest version. Having them all up to date really is the best starting point. I will look out for further dependency updates and make sure to handle them in isolation and in real-time, as soon as you merge this pull request.

I won’t start sending you further updates, unless you have merged this very pull request.

---

🏷 How to check the status of this repository

There is a badge added to your README, indicating the status of this repository.

This is how your badge looks like 👉

🙈 How to ignore certain dependencies

In case you can not, or do not want to update a certain dependency right now, you can of course just change the package.json file back to your liking.

Add a greenkeeper.ignore field to your package.json, containing a list of dependencies you don’t want to update right now.

// package.json
{
  …
  "greenkeeper": {
    "ignore": [
      "package-names",
      "you-want-me-to-ignore"
    ]
  }
}

👩‍💻 How to update this pull request

  # change into your repository’s directory
  git fetch
  git checkout greenkeeper/initial
  npm install-test
  # adapt your code, so it’s working again
  git commit -m 'chore: adapt code to updated dependencies'
  git push origin greenkeeper/initial

✨ How the updates will look like

As soon as you merge this pull request I’ll create a branch for every dependency update, with the new version applied. The branch creation should trigger your testing services to check the new version. Using the results of these tests I’ll try to open meaningful and helpful pull requests and issues, so your dependencies remain working and up-to-date.

-  "underscore": "^1.6.0"
+  "underscore": "^1.7.0"

In the above example you can see an in-range update. 1.7.0 is included in the old ^1.6.0 range, because of the caret ^ character .
When the test services report success I’ll delete the branch again, because no action needs to be taken – everything is fine.
When there is a failure however, I’ll create an issue so you know about the problem immediately.

This way every single version update of your dependencies will either continue to work with your project, or you’ll get to know of potential problems immediately.

-  "lodash": "^3.0.0"
+  "lodash": "^4.0.0"

In this example the new version 4.0.0 is not included in the old ^3.0.0 range.
For version updates like these – let’s call them “out of range” updates – you’ll receive a pull request.

Now you no longer need to check for exciting new versions by hand – I’ll just let you know automatically.
And the pull request will not only serve as a reminder to update. In case it passes your decent test suite that’s a strong reason to merge right away

💁‍♂️ Not sure how things are going to work exactly?

There is a collection of frequently asked questions and of course you may always ask my humans.

---

Good luck with your project and see you soon ✨

Your Greenkeeper Bot 🌴

[gabrielrtakeda]

Dependency Packages Upgrade Annotations

Here I will describe the differences from previous version to desired version to upgrade
for each of the dependency packages.

❌ axios

from 0.15.0 to 0.16.2

• Have a BREAKING CHANGE on 0.16.0

✅ dotenv

from 2.0.0 to 4.0.0

• No breaking changes. It seems ok to upgrade.

✅ helmet

from 2.3.0 to 3.6.1

• No breaking changes reported on the changelog. It seems ok to upgrade.

✅ opn

from 4.0.2 to 5.1.0

• No breaking changes reported. It seems ok to upgrade.

⚠️ raven

from 1.1.4 to 2.1.0

• Maybe a BREAKING CHANGE on 2.0.0. It needs to verify before upgrade.

Be aware when upgrading: it is possible that with raven-node 2.0, your node process will shut down from exceptions where it previously did not

⚠️ react-cookie

from 1.0.4 to 2.0.7

• No changelog file provided and, I cannot be sure if the migration will be smooth. In any case, I opened a question issue in (question) Breaking changes bendotcodes/cookies#89 to kill the doubt.

✅ react-helmet

from 3.1.0 to 5.1.3

• We do not use the PlainComponent
• The New Simplified API in 5.0.0 is fully backward-compatible
• I really believe that is safe to upgrade.

✅ react-redux

from 4.4.0 to 5.0.5

• The v5 is compatible with v4.x as in v5 release note:

Version 5.0 maintains API compatibility with v4.x

❌ react-router

from 2.8.1 to 4.1.1

• Have a BREAKING CHANGES:

v3.0.0-alpha.1

• Breaking: Remove all deprecated functionality as of v2.3.0
• Breaking/Feature: Make and withRouter update inside static containers

v3.0.0-alpha.2

• Breaking: Remove all deprecated functionality as of v2.6.0
• Breaking: Support history v3 instead of history v2

✅ react-s3-uploader

from 3.4.0 to 4.1.1

• It have a breaking change but, it is nothing that we use. So, we can upgrade it.

v4.0.0

• BREAKING CHANGE: Removed unorm and latinize dependencies

✅ redial

from 0.4.1 to 0.5.0

• No breaking changes.

❌ redux-form

from 5.3.2 to 6.8.0

• Too much BREAKING CHANGES to list here. Needs to read the docs to migrate it.

❌ redux-logger

from 2.7.4 to 3.0.6

• It have a BREAKING CHANGE:

3.0.0 — breaking change with exports

• by default it now exports logger with default options and createLogger coming as named import.

[igr-santos]

react-router

Related issue: #705

[gabrielrtakeda]

DevDependency Packages Upgrade Annotations

Here I will describe the differences from previous version to desired version to upgrade
for each of the devDependency packages.

✅ babel-loader

from 6.2.10 to 7.1.0

• It have some breaking changes but, I believe this will not impact our side.. Those changes are described in v7.0.0

✅ babel-plugin-istanbul

from 2.0.0 to 4.1.4

• It have BREAKING CHANGES. But, I think this do not impact us.

v3.0.0

• test-exclude now adds /node_modules/ as exclude rule by default.

v4.0.0

• Dropped Node 0.10 and Node 0.12 support.

✅ babel-plugin-webpack-loaders

from 0.8.0 to 0.9.0

• No changelog file provided but, it was upgraded to a minor version, so I believe it is ok to upgrade it on our side.

⚠️ chai

from 3.5.0 to 4.0.2

• It have 3 BIG BREAKING CHANGES. It needs to understand more deeply which changes will impact us by reading the changes in:
  • 4.0.0-canary.1
  • 4.0.0-canary.2
  • 4.0.0

✅ chai-as-promised

from 6.0.0 to 7.0.0

• Dropped the support of previous version of Node v4.

The breaking change in this release is that it has started using syntax that is only supported on Node.js v4 and above, as previous versions of Node no longer are supported by the Node.js

✅ compression-webpack-plugin

from 0.3.2 to 0.4.0

• No breaking changes in v0.4.0

✅ css-loader

from 0.26.1 to 0.28.4

• No breaking changes.

✅ file-loader

from 0.10.0 to 0.11.2

• No breaking changes. Only bugfixes.

⏭ babel-jest

from 18.0.0 to 20.0.3

• Follows the jest packages version.

❌ jest

from 18.1.0 to 20.0.4

• It have some BREAKING CHANGES:

19.0.0

• Breaking Change: Added a version for snapshots.
• Breaking Change: Removed the mocksPattern configuration option, it never worked correctly.
• Breaking Change: Renamed testPathDirs to roots to avoid confusion when configuring Jest.
• Breaking Change: Updated printing of React elements to cause fewer changes when props change.
• Breaking Change: Updated snapshot format to properly escape data.

20.0.0

• Breaking Change: Forked Jasmine 2.5 into Jest's own test runner and rewrote large parts of Jasmine.
• Breaking Change: Jest does not write new snapshots by default on CI.
• Breaking Change: Moved the typescript parser from jest-editor-support into a separate jest-test-typescript-parser package.
• Breaking Change: Replaced auto-loading of babel-polyfill with only regenerator-runtime, fixes a major memory leak.

❌ nyc

from 8.1.0 to 11.0.3

• It have some BREAKING CHANGES:

9.0.0

• BREAKING CHANGES: /node_modules/ is again excluded by default.

10.0.0

• BREAKING CHANGES: nyc's cache is now enabled by default

11.0.0

• BREAKING CHANGES: new version of find-up requires dropping 0.10/0.12 support

✅ postcss-loader

from 1.2.1 to 2.0.6

• No breaking changes reported.

⚠️ postcss-scss

from 0.4.0 to 1.0.2

• Likely as a breaking change. It needs to check it up.

1.0.0

• Use PostCSS 6.0.
• Use babel-preset-env.

⚠️ sinon

from 1.17.7 to 2.3.5

• The changelog file and release notes are a little confusing. Must check it manually on the code.
• release notes
• changelog file

✅ standard

from 8.0.0 to 10.0.2

8.2.0

• ES7 support: We now can remove the babel-eslint as a custom parser on webpack config

8.3.0

• ES8 support

9.0.0

When you upgrade, consider running standard --fix to automatically fix some of the errors caught by the new rules in this version.

• No breaking changes.

10.0.0

The most important change in 10.0.0 is that using deprecated Node.js APIs is now considered an error. It's finally time to update those dusty old APIs!

• No breaking changes.

⚠️ standard-loader

from 5.0.0 to 6.0.1

• No changelog file provided and, I cannot be sure if the migration will be smooth. In any case, I opened a question issue in (question) Breaking changes v5 to v6 migration standard/standard-loader#86 to kill the doubt.
• But, I believe that is no breaking changes. Just for be sure.

✅ style-loader

from 0.13.1 to 0.18.2

• No breaking changes.

❌ webpack

from 2.2.1 to 3.0.0

• It have some BREAKING CHANGES.

v3.0.0

• node_modules no longer mangle to ~ in stats
• sourceMapFilename now supports [contenthash]
• fixed a few issues with weird stats output
• fixed a bug in occurrence order plugin
• optimization plugins now only affect the current compilation
• context now also include index files
• require.resolve evaluate truthy
• child compilations get records and cache assigned (they need a unique name)
• Set is used for Child.modules and Module.chunks

✅ webpack-dashboard

from 0.3.0 to 0.4.0

• No breaking changes.

[gabrielrtakeda]

@lpirola, I made some tests here and, it seems ok to merge. But, I think it would be better merge it back to the branch develop first, and when we create a release branch, these changes will be merged to branch master, what do you think?