Spellcheck Updates For Concept and Guides Pages (#689)

Spellcheck updates.

Author: Chris Villanueva

content/concepts/configuration.md

@@ -106,7 +106,7 @@ import {
 } from './';
 
 export class NgCliWebpackConfig {
-  // TODO: When webpack2 types are finished lets replace all these any types
+  // TODO: When webpack2 types are finished let's replace all these any types
   // so this is more maintainable in the future for devs
   public config: any;
   private webpackDevConfigPartial: any;

content/concepts/entry-points.md

@@ -3,6 +3,7 @@ title: Entry Points
 sort: 2
 contributors:
   - TheLarkInn
+  - chrisVillanueva
 ---
 
 Like we mentioned in the [introduction](/get-started/#using-webpack-with-a-config), there are multiple ways to define the `entry` property in your webpack configuration. We will show you the ways you **can** configure the `entry` property, in addition to explaining why it may be useful to you.
@@ -21,7 +22,7 @@ const config = {
 module.exports = config;
 ```
 
-The single entry syntax for the `entry` property is a short hand for:
+The single entry syntax for the `entry` property is a shorthand for:
 
 ```javascript
 const config = {

content/concepts/output.md

@@ -232,3 +232,4 @@ The filename of the SourceMaps for the JavaScript files. They are inside the `ou
 `[hash]` is replaced by the hash of the compilation.
 
 > Default: `"[file].map"`
+

content/get-started/why-webpack.md

@@ -3,6 +3,7 @@ title: Why webpack?
 contributors:
   - pksjce
   - bebraw
+  - chrisVillanueva
 sort: 2
 ---
 
@@ -25,7 +26,7 @@ T> Even though webpack core focuses on bundling, you can find a variety of exten
 
 ## Comparison
 
-webpack however is not the only module bundler out there. If you are choosing between using webpack or any of the bundler's below, here is a feature by feature comparison on how webpack fares against the current competition.
+webpack however is not the only module bundler out there. If you are choosing between using webpack or any of the bundlers below, here is a feature by feature comparison on how webpack fares against the current competition.
 
 | Feature | webpack/webpack | jrburke/requirejs | substack/node-browserify | jspm/jspm-cli | rollup/rollup | brunch/brunch |
 |---------|-----------------|-------------------|--------------------------|---------------|---------------|---------------|

content/guides/author-libraries.md

@@ -135,7 +135,7 @@ module.exports = {
 };
 ```
 
-This means that your library expects a dependency named `lodash` to be available in the consumers environment.
+This means that your library expects a dependency named `lodash` to be available in the consumer's environment.
 
 ### Add `libraryTarget`
 

content/guides/code-splitting-libraries.md

@@ -3,11 +3,12 @@ title: Code Splitting - Libraries
 sort: 4
 contributors:
   - pksjce
+  - chrisVillanueva
 ---
 
 A typical application uses third party libraries for framework/functionality needs. Particular versions of these libraries are used and code here does not change often. However, the application code changes frequently.
 
-Bundling application code with third party code would be inefficient. This is because the browser can cache asset files based on the cache header and files can be cached without needing to call the cdn again if it's contents don't change. To take advantage of this, we want to keep the hash of the vendor files constant regardless of application code changes.
+Bundling application code with third party code would be inefficient. This is because the browser can cache asset files based on the cache header and files can be cached without needing to call the cdn again if its contents don't change. To take advantage of this, we want to keep the hash of the vendor files constant regardless of application code changes.
 
 We can do this only when we separate the bundles for vendor and application code.
 

content/guides/dependency-management.md

@@ -3,6 +3,7 @@ title: Dependency Management
 sort: 6
 contributors:
   - ndelangen
+  - chrisVillanueva
 ---
 
 > es6 modules
@@ -92,6 +93,6 @@ The exported function has 3 properties: `resolve`, `keys`, `id`.
     r.keys().forEach(key => cache[key] = r(key));
   }
   importAll(require.context('../components/', true, /\.js$/));
-  // At build-time cache will be polulated with all required modules.
+  // At build-time cache will be populated with all required modules.
   ```
 - `id` is the module id of the context module. This may be useful for `module.hot.accept`.

content/guides/development-vagrant.md

@@ -3,6 +3,7 @@ title: Development - Vagrant
 sort: 12
 contributors:
   - SpaceK33z
+  - chrisVillanueva
 ---
 
 If you have a more advanced project and use [Vagrant](https://www.vagrantup.com/) to run your development environment in a Virtual Machine, you'll often want to also run webpack in the VM.
@@ -67,7 +68,7 @@ The server should be accessible on `http://10.10.10.61:8080` now. If you make a
 
 ## Advanced Usage with nginx
 
-To mimick a more production-like environment, it is also possible to proxy the webpack-dev-server with nginx.
+To mimic a more production-like environment, it is also possible to proxy the webpack-dev-server with nginx.
 
 In your nginx config file, add the following:
 

content/guides/lazy-load-react.md

@@ -3,13 +3,14 @@ title: Lazy Loading - React
 sort: 14
 contributors:
   - iammerrick
+  - chrisVillanueva
 ---
 
 A component can lazily load dependencies without its consumer knowing using higher order functions, or a consumer can lazily load its children without its children knowing using a component that takes a function and collection of modules, or some combination of both.
 
 ## LazilyLoad Component
 
-Lets have a look at a consumer choosing to lazily load some components. The `importLazy` is simply a function that returns the `default` property, this is for Babel/ES2015 interoperability. If you don't need that you can omit the `importLazy` helper. The `importLazy` function simply returns whatever was exported as `export default` in the target module.
+Let's have a look at a consumer choosing to lazily load some components. The `importLazy` is simply a function that returns the `default` property, this is for Babel/ES2015 interoperability. If you don't need that you can omit the `importLazy` helper. The `importLazy` function simply returns whatever was exported as `export default` in the target module.
 
 ```jsx
 <LazilyLoad modules={{
@@ -58,7 +59,7 @@ export LazilyLoadFactory(Highlight, {
 });
 ```
 
-Notice how the consumer of Highlight component had no idea it had a dependency that was lazily loaded? Or that if a user had todos with no code we would never need to load highlight.js? 
+Notice how the consumer of Highlight component had no idea it had a dependency that was lazily loaded? Or that if a user had todos with no code we would never need to load highlight.js?
 
 
 ## The Code

content/guides/migrating.md

@@ -9,6 +9,7 @@ contributors:
   - johnnyreilly
   - jouni-kantola
   - frederikprijck
+  - chrisVillanueva
 ---
 
 ## `resolve.root`, `resolve.fallback`, `resolve.modulesDirectories`
@@ -72,7 +73,7 @@ The new naming conventions are easier to understand and are a good reason to upg
 ## Chaining loaders
 
 Like in webpack v1, loaders can be chained to pass results from loader to loader. Using the [rule.use](/configuration/module#rule-use)
-configuration option, `use` can be set to a list of loaders.
+ configuration option, `use` can be set to a list of loaders.
 In webpack v1, loaders were commonly chained with `!`. This style is only supported using the legacy option `module.loaders`.
 
 ``` diff
@@ -331,48 +332,48 @@ These functions are now always asynchronous instead of calling their callback sy
 You can *no longer* configure a loader with a custom property in the `webpack.config.js`. It must be done through the `options`. The following configuration with the `ts` property is no longer valid with webpack 2:
 
 ```js
-module.exports = { 
+module.exports = {
   ...
-  module: { 
-    rules: [{ 
+  module: {
+    rules: [{
       test: /\.tsx?$/,
       loader: 'ts-loader'
     }]
   },
   // does not work with webpack 2
-  ts: { transpileOnly: false } 
-} 
+  ts: { transpileOnly: false }
+}
 ```
 
 ### What are `options`?
 
 Good question. Well, strictly speaking it's 2 possible things; both ways to configure a webpack loader. Classically `options` was called `query` and was a string which could be appended to the name of the loader. Much like a query string but actually with [greater powers](https://github.com/webpack/loader-utils#parsequery):
 
 ```js
-module.exports = { 
+module.exports = {
   ...
-  module: { 
-    rules: [{ 
+  module: {
+    rules: [{
       test: /\.tsx?$/,
       loader: 'ts-loader?' + JSON.stringify({ transpileOnly: false })
     }]
   }
-} 
+}
 ```
 
 But it can also be a separately specified object that's supplied alongside a loader:
 
 ```js
-module.exports = { 
+module.exports = {
   ...
-  module: { 
-    rules: [{ 
+  module: {
+    rules: [{
       test: /\.tsx?$/,
       loader: 'ts-loader'
       options:  { transpileOnly: false }
     }]
   }
-} 
+}
 ```
 
 ## `LoaderOptionsPlugin` context
@@ -586,7 +587,7 @@ Loaders are now cacheable by default. Loaders must opt-out if they are not cache
 webpack 1 only support `JSON.stringify`-able options for loaders.
 webpack 2 now supports any JS object as loader options.
 
-Using complex options comes with one restriction. You may need to have a `ident` for the option object to make it referencable by other loaders.
+Using complex options comes with one restriction. You may need to have a `ident` for the option object to make it referenceable by other loaders.
 
 Having an `ident` on the options object means to be able to reference this options object in inline loaders. Here is an example: