Fixing a small doc error

docs/guide/application-lifecycle.md

@@ -8,18 +8,18 @@ layout: guide.hbs
 ---
 
 This guide outlines the lifecycle of the backend side of a Zeroth application, as the frontend lifecycle is just standard
-Angular 2. 
+Angular 2.
 
 ## Startup
 Like the frontend, bootstrapping the application happens both in the `main.ts` section of the project, and in the core
-module. The core handles the loading, registration and bootstrapping of both core components and the components that 
+module. The core handles the loading, registration and bootstrapping of both core components and the components that
 are defined in the application.
 
 To kick off the server, the entry javascript file will require the exported `bootstrap()` function. In production, this
  file would be the `./lib/server/server/bootstrap.js` file. In development, this bootstrapping is handle by the cli,
  as it extends the capabilities of the before start to allow the webpack dev sever to run and the file watchers to start
  detecting changes.
- 
+
 ### 1. Configuration
 When first loaded, the `dotenv` library looks for a `.env` file in the current working directory, and exports all variables
  to `process.env`. For more info, see the [Configuration Section](/guide/configuration) of the guide
@@ -29,6 +29,7 @@ Next, all of the entities of the application are loaded. In your `main.ts` file,
 ```typescript
 import * as models from '../common/models';
 import * as controllers from './controllers';
+import * as seeders from './seeders';
 import * as migrations from './migrations';
 
 let loadClasses = [
@@ -59,12 +60,12 @@ array. A general rule of thumb is that if a class uses an entity decorator like
 needs to be imported into the `loadClasses` array. All of the entity decorators are bootstrapped and registered with the
 injector separately, so they do not need to be in the providers array. You would only want to explicitly provide a decorated
 entity if you are substituting an implementation, or have some funky factory requirements.
- 
+
 ### 4. Bootstrap
 The bootstrapping is in itself a multi-phase process. The core exports a `bootstrap` function, which is invoked with the
 entities and providers defined above.
 1. The bootstrapping is deferred until all provider promises have resolved. If *any* are rejected, bootstrapping is aborted.
-1. Specialist bootstrappers for each Entity type (models, migrations, seeders, controllers) retrieve the injectable instances 
+1. Specialist bootstrappers for each Entity type (models, migrations, seeders, controllers) retrieve the injectable instances
 from the core registry and when appropriate, resolve them with the `ReflectiveInjector`
 1. A new `injector` instance is created using the passed providers and newly resolved entities
 1. Any logs that have been buffered up to this point are output with the newly resolved concrete `Logger` implementation