Improve README.md

Author: piotr-oles

README.md

@@ -2,12 +2,12 @@
 [![Npm version](https://img.shields.io/npm/v/fork-ts-checker-webpack-plugin.svg?style=flat-square)](https://www.npmjs.com/package/fork-ts-checker-webpack-plugin)
 [![Build Status](https://travis-ci.org/Realytics/fork-ts-checker-webpack-plugin.svg?branch=master)](https://travis-ci.org/realytics/fork-ts-checker-webpack-plugin)
 
-Webpack plugin that runs typescript type checker (with optional linter) on separate processes.
+Webpack plugin that runs typescript type checker on a separate process.
 
 ## Installation ##
 This plugin requires minimum **webpack 2**, **typescript 2.1** and optionally **tslint 5.0**
 ```sh
-npm install --save fork-ts-checker-webpack-plugin
+npm install --save-dev fork-ts-checker-webpack-plugin
 ```
 Basic webpack config (with [ts-loader](https://github.com/TypeStrong/ts-loader))
 ```js
@@ -43,18 +43,17 @@ var webpackConfig = {
 
 ## Motivation ##
 There is already similar solution - [awesome-typescript-loader](https://github.com/s-panferov/awesome-typescript-loader). You can
-add `CheckerPlugin` and delegate checker to the separate process. The problem with `awesome-typescript-loader` is that it's a lot slower 
-than [ts-loader](https://github.com/TypeStrong/ts-loader) on incremental build in our case (~20s vs ~3s).
-Secondly, we use [tslint](https://palantir.github.io/tslint/) and we wanted to run this also on separate process.
-This is why we've created this plugin. The performance is great because of reusing Abstract Syntax Trees between compilations and sharing 
-these trees with tslint. We can also scale checker with multi-process mode - it will split work between processes to utilize maximum cpu 
-power.
+add `CheckerPlugin` and delegate checker to the separate process. The problem with `awesome-typescript-loader` was that, in our case,
+it was a lot slower than [ts-loader](https://github.com/TypeStrong/ts-loader) on an incremental build (~20s vs ~3s).
+Secondly, we use [tslint](https://palantir.github.io/tslint/) and we wanted to run this, along with type checker, in a separate process.
+This is why we've created this plugin. To provide better performance, plugin reuses Abstract Syntax Trees between compilations and shares 
+these trees with tslint. It can be scaled with a multi-process mode to utilize maximum CPU power.
 
 ## Options ##
 **tsconfig** `string` - Path to tsconfig.json file. If not set, plugin will use `path.resolve(compiler.options.context, './tsconfig.json')`.
 
 **tslint** `string | false` - Path to tslint.json file. If not set, plugin will use `path.resolve(compiler.options.context, './tslint.json')`. 
-                            If `false`, disables tslint.
+                              If `false`, disables tslint.
 
 **watch** `string | string[]` - Directories or files to watch by service. Not necessary but improves performance 
                                 (reduces number of `fs.stat` calls).
@@ -72,18 +71,17 @@ power.
 
 **silent** `boolean` - If `true`, logger will not be used. Default: `false`.
 
-**workers** `number` - You can split type checking to few workers to speed-up on increment build. 
-                       **Be careful** - if you don't want to increase build time, you should keep 1 core for *build* and 1 core for 
-                       *system* free *(for example system with 4 cpu threads should use max 2 workers)*. 
-                       Second thing - node doesn't share memory between workers so keep in mind that memory usage will increase 
-                       linearly. If you want to use workers, please experiment with workers number. In some scenarios increasing this number 
-                       **can increase check time** (and of course memory consumption).
+**workers** `number` - You can split type checking to a few workers to speed-up increment build. 
+                       **Be careful** - if you don't want to increase build time, you should keep free 1 core for *build* and 1 core for 
+                       a *system* *(for example system with 4 CPUs should use max 2 workers)*. 
+                       Second thing - node doesn't share memory between workers - keep in mind that memory usage will increase. 
+                       Be aware that in some scenarios increasing workers number **can increase checking time**.
                        Default: `ForkTsCheckerWebpackPlugin.ONE_CPU`.
 
 Pre-computed consts:      
-  * `ForkTsCheckerWebpackPlugin.ONE_CPU` - always use one cpu (core)
-  * `ForkTsCheckerWebpackPlugin.ONE_CPU_FREE` - leave only one cpu for build (probably will increase build time)
-  * `ForkTsCheckerWebpackPlugin.TWO_CPUS_FREE` - leave two cpus free (one for build, one for system)
+  * `ForkTsCheckerWebpackPlugin.ONE_CPU` - always use one CPU
+  * `ForkTsCheckerWebpackPlugin.ONE_CPU_FREE` - leave only one CPU for build (probably will increase build time)
+  * `ForkTsCheckerWebpackPlugin.TWO_CPUS_FREE` - leave two CPUs free (one for build, one for system)
 
 **memoryLimit** `number` - Memory limit for service process in MB. If service exits with allocation failed error, increase this number.
                            Default: `2048`.