Merge pull request #2173 from zzzzBov/patch-1

Fixed minor formatting issues

tests/dummy/app/pods/docs/advanced/server-configuration/template.md

@@ -1,60 +1,61 @@
 # Server configuration
 
-The MirageJS server is configured for you by ember-cli-mirage. However, if you need to customize the server you can by creating a makeServer function in the config.js.
+The MirageJS server is configured for you by ember-cli-mirage. However, if you
+need to customize the server you can by creating a makeServer function in the
+config.js.
 
 The named `makeServer` function export gives you a lower-level way to hook
-  into how your Ember app instantiates your Mirage JS server.
-
-  Typically, the `/mirage/config.js` file contains a single default export which
-  is a function defining all your Mirage route handlers. Ember CLI Mirage then
-  uses this function, along with all the other modules you've defined in
-  `mirage/models`, `mirage/fixtures`, `mirage/factories`, and
-  `mirage/serializers`, to create your Mirage JS server when your app boots up
-  in development and testing.
-
-  You can now opt in to having more control over exactly how your Mirage server
-  is instantiated, as well as the ability to use imports directly from the
-  `miragejs` npm package, by exporting a single named function called
-  `makeServer` instead.
-
-  `makeServer` receives a single argument called `config`, which contains all
-  the factory/fixture/serializer/model modules that exist in your project's
-  `/mirage` directory. This saves you from having to import each module
-  explicitly and then pass it into your Mirage server, just like you're used to
-  with the default setup.
-
-  The `config` argument maps exactly to everything inside of your `/mirage`
-  directory - notably, it does not contain the autogenerated Mirage model
-  definitions derived from your Ember Data models, which is an important feature
-  of Ember CLI Mirage that is enabled by default. To replicate this behavior
-  when using `makeServer`, we have provided an additional import called
-  `discoverEmberDataModels` from the `ember-cli-mirage` package that you can use
-  to augment your config with these models so that your Mirage schema is
-  automatically inferred from your host application's Ember Data models and
-  relationships. The snippet below shows how to do this. Note that the order
-  here matters if you also have models defined in your `/mirage/models`
-  directory, as those model definitions would "win" in the event of a conflict
-  with the ones autodiscovered from Ember Data. (However, most of time if you
-  are inferring your Mirage schema from Ember Data, you shouldn't need to define
-  additional models.)
-
-  Finally, your route handlers just need to be passed to the `routes()` key in
-  your Mirage config. You can do this inline, or you can make them a separate
-  function, and organize that function however you choose.
-
-  The only thing needed to enable this behavior is that you delete the default
-  function export and instead export a single named function called
-  `makeServer`. You should also add `miragejs` to your project's dependencies in
-  your `package.json` file, since you are now importing directly from it. Note
-  that this gives you the added benefit of being able to upgrade `miragejs`
-  independently of `ember-cli-mirage`.
-
-  Eventually, `ember-cli-mirage` will shed its re-exports of everything from
-  `miragejs`, and become a small wrapper library delegating the rest of the work
-  to `miragejs`. This will help align the Ember Mirage users with the rest of
-  the Mirage JS community. 
+into how your Ember app instantiates your Mirage JS server.
+
+Typically, the `/mirage/config.js` file contains a single default export which
+is a function defining all your Mirage route handlers. Ember CLI Mirage then
+uses this function, along with all the other modules you've defined in
+`mirage/models`, `mirage/fixtures`, `mirage/factories`, and
+`mirage/serializers`, to create your Mirage JS server when your app boots up
+in development and testing.
+
+You can now opt in to having more control over exactly how your Mirage server
+is instantiated, as well as the ability to use imports directly from the
+`miragejs` npm package, by exporting a single named function called
+`makeServer` instead.
+
+`makeServer` receives a single argument called `config`, which contains all
+the factory/fixture/serializer/model modules that exist in your project's
+`/mirage` directory. This saves you from having to import each module
+explicitly and then pass it into your Mirage server, just like you're used to
+with the default setup.
+
+The `config` argument maps exactly to everything inside of your `/mirage`
+directory - notably, it does not contain the autogenerated Mirage model
+definitions derived from your Ember Data models, which is an important feature
+of Ember CLI Mirage that is enabled by default. To replicate this behavior
+when using `makeServer`, we have provided an additional import called
+`discoverEmberDataModels` from the `ember-cli-mirage` package that you can use
+to augment your config with these models so that your Mirage schema is
+automatically inferred from your host application's Ember Data models and
+relationships. The snippet below shows how to do this. Note that the order
+here matters if you also have models defined in your `/mirage/models`
+directory, as those model definitions would "win" in the event of a conflict
+with the ones autodiscovered from Ember Data. (However, most of time if you
+are inferring your Mirage schema from Ember Data, you shouldn't need to define
+additional models.)
+
+Finally, your route handlers just need to be passed to the `routes()` key in
+your Mirage config. You can do this inline, or you can make them a separate
+function, and organize that function however you choose.
+
+The only thing needed to enable this behavior is that you delete the default
+function export and instead export a single named function called
+`makeServer`. You should also add `miragejs` to your project's dependencies in
+your `package.json` file, since you are now importing directly from it. Note
+that this gives you the added benefit of being able to upgrade `miragejs`
+independently of `ember-cli-mirage`.
+
+Eventually, `ember-cli-mirage` will shed its re-exports of everything from
+`miragejs`, and become a small wrapper library delegating the rest of the work
+to `miragejs`. This will help align the Ember Mirage users with the rest of
+the Mirage JS community.
 ```javascript
-
 // Example with inline routes
 import { createServer, discoverEmberDataModels } from "ember-cli-mirage";