Update dependencies to enable Greenkeeper 🌴

[greenkeeper]

Let’s get started with automated dependency management for webcompat.com 💪

This pull request updates all your dependencies to their latest version. Having them all up to date really is the best starting point for keeping up with new releases. Greenkeeper will look out for further dependency updates and make sure to handle them in isolation and in real-time, but only after you merge this pull request.

Important: Greenkeeper will only start watching this repository’s dependency updates after you merge this initial pull request.

---

🏷 How to check the status of this repository

Greenkeeper adds a badge to your README which indicates the status of this repository.

This is what your badge looks like right now 👉

🙈 How to ignore certain dependencies

You may have good reasons for not wanting to update to a certain dependency right now. In this case, you can change the dependency’s version string in the package.json file back to whatever you prefer.

To make sure Greenkeeper doesn’t nag you again on the next update, add a greenkeeper.ignore field to your package.json, containing a list of dependencies you don’t want to update.

// 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 --all
  git checkout greenkeeper/initial
  npm install-test
  # Adapt your code until everything works again
  git commit -m 'chore: adapt code to updated dependencies'
  git push https://github.com/webcompat/webcompat.com.git greenkeeper/initial

✨ How do dependency updates work with Greenkeeper?

After you merge this pull request, Greenkeeper will create a new branch whenever a dependency is updated, with the new version applied. The branch creation should trigger your testing services and check whether your code still works with the new dependency version. Depending on the the results of these tests Greenkeeper will 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"

The above example shows 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 Greenkeeper will silently delete the branch again, because no action needs to be taken – everything is fine.

However, should the tests fail, Greenkeeper will create an issue to inform you about the problem immediately.

This way, you’ll never be surprised by a dependency breaking your code. As long as everything still works, Greenkeeper will stay out of your way, and as soon as something goes wrong, you’ll be the first to know.

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

This means that you no longer need to check for new versions manually – Greenkeeper will keep you up to date automatically.

These pull requests not only serve as reminders to update: If you have solid tests and good coverage, and the pull requests passes those tests, you can very likely just merge it and release a new version of your software straight away

To get a better idea of which ranges apply to which releases, check out the extremely useful semver calculator provided by npm.

FAQ and help

There is a collection of frequently asked questions. If those don’t help, you can always ask the humans behind Greenkeeper.

---

Good luck with your project and see you soon ✨

Your Greenkeeper bot 🌴

[magsout]

r @miketaylr ?

[miketaylr]

Thanks @magsout. I'll need to run tests manually, because we haven't turned on shared secrets for CircleCI just yet. But we have a plan in place.

[miketaylr]

Depends on #2637

[miketaylr]

I'll need to run tests manually

actually no, let's just wait until we can run PRs for forks.

[magsout]

@miketaylr hum, why you said "I'll need to run tests manually" ?

greenkeeper gets acces to our repo, so it makes PR directly from webcompat not a fork?

[miketaylr]

greenkeeper gets acces to our repo, so it makes PR directly from webcompat not a fork?

...oh. :)

I see now that "Your tests passed on CircleCI!"

@karlcow, I know you had concerns. Any hard objections? For me, I think we should try it out and see how it goes for a few months.

[miketaylr]

Removing blocked keyword, but let's wait to hear from @karlcow before merging.

[greenkeeper]

Hey there 👋,

we noticed that this PR isn’t merged yet. Just to let you know: if you don't merge this PR, Greenkeeper will not be enabled on this repo, and you won't receive updates for your dependencies.

If you don't want to enable Greenkeeper here, just close or ignore this PR, we won't nag you again. ✌️

Have a great day! 🌴

[miketaylr]

Removing blocked keyword, but let's wait to hear from @karlcow before merging.

Ping @karlcow

[karlcow]

Yeah I'm not a big fan of greenkeeper for two reasons:

1. It's very noisy (seen that on webcompat-metrics project)
2. And the old adage: If it's not broken, don't touch it.

Now I'm not totally familiar with greenkeeper. What are the risks that greenkeeper will break things? Why do we need to update libraries if not using a specific feature? and/or security issues?

Apart of that technically this PR seems to be working. :)

So… I don't know. You both know better the node world.

[magsout]

@karlcow

It's very noisy (seen that on webcompat-metrics project)

Yes, true.

And the old adage: If it's not broken, don't touch it.

heh

Now I'm not totally familiar with greenkeeper. What are the risks that greenkeeper will break things? Why do we need to update libraries if not using a specific feature? and/or security issues?

No really risking because greenkeeper opens PR only and only if All checks have passed with circle.

I find it's a painful to update dependencies every time. greenkeeper does it for us.

[karlcow]

I find it's a painful to update dependencies every time. greenkeeper does it for us.

1. Is there a way to set it up in a way that it adjusts only if it's a security update?
2. Do you know if it can create breakage? (updating with incompatible changes).
   Reading the docs right now and I see that it opens an issue if one of our tests breaks (which implies you need to have tests :D untested features will not break with CircleCI.)
3. What does it do for the users who have their local project. Does that mean, we need to do npm install everytime?

As I said both @magsout and @miketaylr have a better knowledge than me, feel free to merge

[karlcow]

@magsout @miketaylr what is your decision on this? Do I merge it?

There is a flag "do not merge."

[magsout]

@karlcow

Is there a way to set it up in a way that it adjusts only if it's a security update?
hum no, because there is no security update flag on npm or github

2)Do you know if it can create breakage? (updating with incompatible changes).
Reading the docs right now and I see that it opens an issue if one of our tests breaks (which implies you need to have tests :D untested features will not break with CircleCI.)

Good point. But GK updates only package in the scope of our package.json, so no major, so no break?

What does it do for the users who have their local project. Does that mean, we need to do npm install everytime?

yep, they do. But there is a warning when you install or build the project.

[magsout]

@karlcow I'm in favor of.

[karlcow]

ok. Now that we have thumbs up from @magsout and @miketaylr
I'm removing the status: do not merge.