Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Update dependencies to enable Greenkeeper 🌴 #2323

Merged
merged 4 commits into from
Feb 4, 2019

Conversation

greenkeeper[bot]
Copy link

@greenkeeper greenkeeper bot commented Jan 31, 2019

Fixes #2322

Let’s get started with automated dependency management for loopback-next 💪

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.

📦 📦 Greenkeeper has detected multiple package.json files. They have all been added to a new greenkeeper.json config file. They’ve been collected in a group called default, meaning that all of them will receive updates together. You can rename, add and remove groups and freely assign each package.json to whichever group you like. It’s common, for example, to have one frontend group and one backend group, each with a couple of package.json files. In any case, all files in a group will have their updates collected into single PRs and issues.


💥 Tests on this branch are failing. Here’s how to proceed.

To solve the issue, first find out which of the dependency’s updates is causing the problem. Then fix your code to accomodate the changes in the updated dependency. next-update is a really handy tool to help you with this.

Then push your changes to this branch and merge it.

🙈 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/strongloop/loopback-next.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 :shipit:

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 🌴

@raymondfeng
Copy link
Contributor

I updated the PR to make commit messages complied with our convention.

@bajtos
Copy link
Member

bajtos commented Feb 1, 2019

@raymondfeng please squash ab2b920 and 5d6b516 together. Or perhaps better, move ab2b920 into a new pull request that will bump up the dependency version and make the necessary fixes in a single comment.

The rest of changes look reasonable to me.

@bajtos
Copy link
Member

bajtos commented Feb 1, 2019

IIUC, whenever we start a new package in our monorepo, we also have to update greenkeeper.json. Please capture this step in our docs - see Adding a new package, subsection Register the new package in particular.

It would be great if your update-greenkeeper-json.js could have a mode where it checks whether Greenkeeper configuration is up-to-date. That way we could setup a Travis CI task that can detect the problem automatically for us.

@raymondfeng
Copy link
Contributor

@bajtos I added logic to detect if update is required for greenkeeper.json and made it part of npm install. PTAL.

@@ -22,12 +22,13 @@
"typescript": "^3.3.1"
},
"scripts": {
"postinstall": "lerna bootstrap",
"postinstall": "lerna bootstrap && npm run -s update-greenkeeper-json",
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is not really solving the problem, is it? If the person does not run install after adding a new package, or perhaps revert changes made to greepkeeper config, then we won't know the pull request is not complete.

What I would like to see instead:

  • when update-greenkeeper-json.js is run with no arguments (or perhaps with a special new arg), and the config file requires an update, then the tool exits with non-zero status code
  • add a new entry to .travisyml to run consistency check, see commit-lint and code-lint for inspiration
  • add a new code block to bin/travis.sh implementing the new check by running update-greenkeeper-json.js

I am ok to defer this changes to a follow-up pull request if you prefer.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Let's get greenkeeper to do the job first as it awaits this PR to be landed :-).

@bajtos bajtos added the Internal Tooling Issues related to our tooling and monorepo infrastructore label Feb 4, 2019
@raymondfeng raymondfeng merged commit a8a409c into master Feb 4, 2019
@greenkeeper greenkeeper bot deleted the greenkeeper/initial branch February 4, 2019 15:33
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Internal Tooling Issues related to our tooling and monorepo infrastructore
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Action required: Greenkeeper could not be activated 🚨
2 participants