Merge branch 'release/1.0.11'

CONTRIBUTING.md

@@ -46,7 +46,7 @@ git config user.email "[email protected]"
 
 #### Hotfixes and Support branches
 
-It's basically the same process but use the word `hotfix` or `support` instead of `feature`.  `git flow` knows what to do. Just keep in mind that any changes are going to happen to your fork, and not the upstream repo. If you need to merge a `hotfix` into upstream master you may only do it va a reviewed pull request.
+It's basically the same process but use the word `hotfix` or `support` instead of `feature`. `git flow` knows what to do. Just keep in mind that any changes are going to happen to your fork, and not the upstream repo. If you need to merge a `hotfix` into upstream master you may only do it va a reviewed pull request.
 
 ### Releasing to production
 
@@ -56,7 +56,7 @@ It's basically the same process but use the word `hotfix` or `support` instead o
 4. Now go back to GitHub and raise a Pull Request to merge the upstream master from your fork's `master` branch. When that goes through you are done.
 5. In your command-line go back and clean up any outstanding branches and `git pull upstream` your local `master` and `develop` branches to ensure everything on your local machine is up to date with everyone's changes.
 
-Note you will **never** push changes directly to the upstream project, *only to your own fork*.
+Note you will **never** push changes directly to the upstream project, _only to your own fork_.
 
 **Changes may only be introduced into the upstream project via a properly reviewed pull request.**
 
@@ -72,27 +72,27 @@ Note this will creating a feature via `git flow` will create a branch called `fe
 
 ### Commit Messages
 
-When commiting something use the `-m` flag to add a short commit message of the format `{issue number} summary of what you changed`.  So for example if you are working on issue `ABC-1` and you added a method to the `aardvark_controller` you might use the following commit message `"ABC-1 added anteater method to aardvark controller"`
+When commiting something use the `-m` flag to add a short commit message of the format `{issue number} summary of what you changed`. So for example if you are working on issue `ABC-1` and you added a method to the `aardvark_controller` you might use the following commit message `"ABC-1 added anteater method to aardvark controller"`
 
 Commit messages ought to be in the past tense.
 
 In general try to group file changes wherever appropriate, so if your controller change also involved updating something in a helper file, the one commit message can happily encompas the changes to both files. The message ought to reflect the main aim of the change.
 
 ### Pull Requests
 
-Pull requests must be named as follows `[issue type, issue number] high level description of change`.  The following Issue Types are recognised
+Pull requests must be named as follows `[issue type, issue number] high level description of change`. The following Issue Types are recognised
 
-* `Bug Fix` - the change fixes a bug
-* `Feature` - the change adds a new feature (the usual issue type)
-* `Documentation` — The change is a documentation only change
-* `Optimisation` - The change is an optimisation of the code base without any functional changes
+- `Bug Fix` - the change fixes a bug
+- `Feature` - the change adds a new feature (the usual issue type)
+- `Documentation` — The change is a documentation only change
+- `Optimisation` - The change is an optimisation of the code base without any functional changes
 
 If your change does not fit any of these categories, use `Feature`. Likewise if your change is not tied to an issue number you may use `n/a` instead.
 
 So to use the above example your Pull Request would be named `[Feature, ABC-1] added anteater to aardvark`
 
 ### You built it, you merge it
 
-A developer must be responsible for their own work, from accepting a task through to merging to production.  With that in mind if you review another developer's PR, please don't then merge it yourself.  As a general rule you must let the developer merge her own PRs.
+A developer must be responsible for their own work, from accepting a task through to merging to production. With that in mind if you review another developer's PR, please don't then merge it yourself. As a general rule you must let the developer merge her own PRs.
 
-Likewise, don't expect someone else to merge your PR.  Unless you do not have write permission on a project, you will always aim to take personal responsibility for the quality of the code that gets merged in.
+Likewise, don't expect someone else to merge your PR. Unless you do not have write permission on a project, you will always aim to take personal responsibility for the quality of the code that gets merged in.

README.md

@@ -6,6 +6,7 @@ A collection of utilities to help with unit-testing [Sequelize](http://docs.sequ
 
 ## Branches
 
+<!-- prettier-ignore -->
 | Branch | Status | Coverage |   |
 | ------ | ------ | -------- | - |
 | `develop` | [![CircleCI](https://circleci.com/gh/davesag/sequelize-test-helpers/tree/develop.svg?style=svg)](https://circleci.com/gh/davesag/sequelize-test-helpers/tree/develop) | [![codecov](https://codecov.io/gh/davesag/sequelize-test-helpers/branch/develop/graph/badge.svg)](https://codecov.io/gh/davesag/sequelize-test-helpers) | Work in progress |
@@ -15,7 +16,7 @@ A collection of utilities to help with unit-testing [Sequelize](http://docs.sequ
 
 ## Related Projects
 
-* [`sequelize-pg-utilities`](https://github.com/davesag/sequelize-pg-utilities) — Simple utilities that help you manage your Sequelize configuration.
+- [`sequelize-pg-utilities`](https://github.com/davesag/sequelize-pg-utilities) — Simple utilities that help you manage your Sequelize configuration.
 
 ## How to use
 
@@ -30,7 +31,9 @@ This library assumes:
 
 Add `sequelize-test-helpers` as a `devDependency`:
 
-    npm i -D sequelize-test-helpers
+```
+npm i -D sequelize-test-helpers
+```
 
 ## Examples
 
@@ -150,14 +153,15 @@ describe('src/models/User', () => {
 
 ### Built in checks
 
-| Check                      | What it does                                             |
-| -------------------------- | -------------------------------------------------------- |
-| `checkHookDefined`         | Checks that a particular hook is defined.                |
-| `checkModelName`           | Checks that the model is named correctly.                |
-| `checkNonUniqueIndex`      | Checks that a specific non-unique index is defined.      |
-| `checkPropertyExists`      | Checks that the model has defined the given property.    |
+<!-- prettier-ignore -->
+| Check                 | What it does |
+| --------------------- | ------------ |
+| `checkHookDefined`    | Checks that a particular hook is defined. |
+| `checkModelName`      | Checks that the model is named correctly. |
+| `checkNonUniqueIndex` | Checks that a specific non-unique index is defined. |
+| `checkPropertyExists` | Checks that the model has defined the given property. |
 | `checkUniqueCompoundIndex` | Checks that a specific unique compound index is defined. |
-| `checkUniqueIndex`         | Checks that a specific unique index is defined.          |
+| `checkUniqueIndex`    | Checks that a specific unique index is defined. |
 
 ### Checking associations