fix(deps): update deps, renovate config, contrib file

TAG: latest

CONTRIBUTING.md

@@ -41,15 +41,15 @@ You should usually open an issue in the following situations:
 - **If you see an open issue that you want to tackle,** comment on the issue to let people know you're on it. That way, people are less likely to duplicate your work.
 - **If an issue was opened a while ago,** it's possible that it's being addressed somewhere else, or has already been resolved, so comment to ask for confirmation before starting work.
 - **If you opened an issue, but figured out the answer later on your own,** comment on the issue to let people know, then close the issue. Even documenting that outcome is a contribution to the project.
-- **Please be patient** and _wait_ a response from maintainer or somebody else. Check out [_"What to do next?"_](https://github.com/tunnckoCore/contributing#what-can-i-do-while-im-waiting).
+- **Please be patient** and _wait_ for a response from the maintainer or somebody else. Check out [_"What to do next?"_](https://github.com/tunnckoCore/contributing#what-can-i-do-while-im-waiting).
 
 ### Include Any/All _Relevant_ Information in the _Issue Description_
 
-- Please _include_ as much ***relevant information*** as you can like versions and operating system.
+- Please _include_ as much ***relevant information*** as you can, such as versions and operating system.
 - A _good_ issue _describes_ the idea in a _**concise** and **user-focused**_ way.
-- ***Never*** leave the issue _description_ blank even when you are in a "rush" - the point of issues is to _communicate_.
+- ***Never*** leave the issue _description_ blank even when you are in a "rush" - the point of an issue is to _communicate_.
 
-**Why not empty description?** You _wouldn't_ send a _blank email_ to hundreds of your friends (_unless you wanted to freak them out!_), right? Submitting _blank issues_ is doing **exactly** that! It sends a ["_I have **no idea** what I'm doing_"](https://www.google.com/search?q=i+have+no+idea+what+i%27m+doing&tbm=isch) **message** to your _peers_.
+**Why can't the description be empty?** You _wouldn't_ send a _blank email_ to hundreds of your friends (_unless you wanted to freak them out!_), right? Submitting _blank issues_ is doing **exactly** that! It sends a ["_I have **no idea** what I'm doing_"](https://www.google.com/search?q=i+have+no+idea+what+i%27m+doing&tbm=isch) **message** to your _peers_.
 
 <!-- Part 3 -->
 
@@ -68,19 +68,19 @@ A pull request doesn't have to represent finished work. It's usually better to o
 
 ### Pro Tips to follow
 
-- **Don't mind about the style** because we use [StandardJS](https://github.com/standard/standard), [ESLint](https://github.com/eslint/eslint) and [Prettier](https://github.com/prettier/prettier). Use `npm run lint` command.
-- **Don't change the markdown files**, because the README is generated (it isn't hand written) and the API section is from JSDoc code comments. Let this step to us when _and if_ pull request is merged.
-- **Dont't comment tests**, instead use `test.skip`. They'll still be shown in the output, but are never run.
+- **Don't worry about the style** because we use [StandardJS](https://github.com/standard/standard), [ESLint](https://github.com/eslint/eslint) and [Prettier](https://github.com/prettier/prettier). Use the `npm run lint` command.
+- **Don't change the markdown files**, because the README is generated (it isn't hand written) and the API section is from JSDoc code comments. Leave this step to us when, _and if_, the pull request is merged.
+- **Don't comment out tests**, instead use `test.skip`. They'll still be shown in the output, but are never run.
 
 ### How to submit a pull request
 
 There are just **8 easy steps** you should do. _**Please**_, follow them in _that exact_ order.
 
 1. **[Fork the repository](https://guides.github.com/activities/forking/)** and clone it locally.
 2. **[Create a branch](https://guides.github.com/introduction/flow/)** for your edits.
-3. **Install dependencies** by running `npm install` command.
-4. **Test everything is working** before you start _doing anything_ with `npm test` command. If something is wrong, please report it first and don't continue if you can't skip the problem easily.
-5. **Reference any relevant issues** or supporting documentation or information in your PR (ex. "Closes #37.")
+3. **Install dependencies** by running the `npm install` command.
+4. **Test if everything is working** before you start _doing anything_ with the `npm test` command. If something is wrong, please report it first and don't continue if you can't skip the problem easily.
+5. **Reference any relevant issues**, supporting documentation or information in your PR (ex. "Closes #37.")
 6. **Test again or add new ones!** Run `npm test` again to _make sure_ your changes don't break existing tests.
 7. **Commit your changes** by running `npm run commit`. It _will lead you_ through what the commit message _should look like_ and will run more tasks **to ensure** that code style and tests are okey. 
 8. **Wait response!** What to do in that time? Check out [_**"What to do next?"**_](https://github.com/tunnckoCore/contributing#what-can-i-do-while-im-waiting).

package.json

@@ -11,6 +11,7 @@
   "license": "MIT",
   "scripts": {
     "fresh": "hela fresh",
+    "contrib": "hela contrib",
     "renovate": "hela renovate",
     "lint": "hela lint -c .eslintrc.json",
     "pretest": "hela build && hela pretest",
@@ -40,7 +41,7 @@
     "eslint-config-standard-tunnckocore": "1.0.3",
     "espree": "3.5.0",
     "for-in": "1.0.2",
-    "hela": "0.4.2",
+    "hela": "0.5.3",
     "husky": "0.14.3",
     "semantic-release": "^6.3.6"
   },

renovate.json

@@ -9,9 +9,6 @@
     "renovate"
   ],
   "prCreation": "not-pending",
-  "schedule": [
-    "every 15 mins every weekday"
-  ],
   "depTypes": [
     {
       "depType": "dependencies",