Use correct spelling (https://webpack.js.org/branding/#the-name)

src/_posts/012-release.md

@@ -62,16 +62,16 @@ Vue.component('async-example', function (resolve, reject) {
 })
 ```
 
-It is up to you to decide how to load the component from the server, e.g. `$.getScript()` or require.js; but the recommended usage is to pair it up with Webpack's [Code Splitting feature](http://webpack.github.io/docs/code-splitting.html):
+It is up to you to decide how to load the component from the server, e.g. `$.getScript()` or require.js; but the recommended usage is to pair it up with webpack's [Code Splitting feature](http://webpack.github.io/docs/code-splitting.html):
 
 ``` js
 Vue.component('async-webpack-example', function (resolve, reject) {
-  // In Webpack AMD like syntax indicates a code split point
+  // In webpack AMD like syntax indicates a code split point
   require(['./my-async-component'], resolve)
 })
 ```
 
-That's all you need to do. You can use the component just like before, without even thinking about it being async. Webpack will automatically split your final JavaScript into separate bundles with correct dependencies, and automatically load a bundle via Ajax when it is required. You can check out a fully functional example [here](https://github.com/vuejs/vue-webpack-example).
+That's all you need to do. You can use the component just like before, without even thinking about it being async. webpack will automatically split your final JavaScript into separate bundles with correct dependencies, and automatically load a bundle via Ajax when it is required. You can check out a fully functional example [here](https://github.com/vuejs/vue-webpack-example).
 
 ### Improved Transition System
 

src/_posts/march-update.md

@@ -19,7 +19,7 @@ There are many other great projects - too many to be listed here - but you can c
 
 ## A New Vision For the Project
 
-Some of you may have noticed that the development on the Vue.js core repo has slowed down lately - in the meanwhile, a lot of efforts went into other sub projects, namely [Vuex](https://github.com/vuejs/vuex), [vue-devtools](https://github.com/vuejs/vue-devtools) and the official [Webpack project boilerplate](https://github.com/vuejs-templates/webpack). The next step is a new release for [vue-router](https://github.com/vuejs/vue-router), and better documentation/examples demonstrating how Vue.js core, Vuex and vue-router work together in a large single page application.
+Some of you may have noticed that the development on the Vue.js core repo has slowed down lately - in the meanwhile, a lot of efforts went into other sub projects, namely [Vuex](https://github.com/vuejs/vuex), [vue-devtools](https://github.com/vuejs/vue-devtools) and the official [webpack project boilerplate](https://github.com/vuejs-templates/webpack). The next step is a new release for [vue-router](https://github.com/vuejs/vue-router), and better documentation/examples demonstrating how Vue.js core, Vuex and vue-router work together in a large single page application.
 
 All this adds together towards a new vision for the Vue.js project: a progressive framework that can adapt to different complexity levels. Vue.js core will remain "just the view layer" - you can still drop it on whatever existing page to replace jQuery, but the Vue.js project also includes other pieces like vue-router, Vuex, vue-loader/vueify and vue-cli that works together as a more complete, opinionated framework for single page applications. More on this in a later post.
 

src/_posts/vue-cli.md

@@ -34,9 +34,9 @@ Current available templates include:
 
 - [browserify-simple](https://github.com/vuejs-templates/browserify-simple) - A simple Browserify + vueify setup for quick prototyping.
 
-- [webpack](https://github.com/vuejs-templates/webpack) - A full-featured Webpack + vue-loader setup with hot reload, linting, testing & css extraction.
+- [webpack](https://github.com/vuejs-templates/webpack) - A full-featured webpack + vue-loader setup with hot reload, linting, testing & css extraction.
 
-- [webpack-simple](https://github.com/vuejs-templates/webpack-simple) - A simple Webpack + vue-loader setup for quick prototyping.
+- [webpack-simple](https://github.com/vuejs-templates/webpack-simple) - A simple webpack + vue-loader setup for quick prototyping.
 
 ### Bring Your Own Setup
 

src/_posts/why-no-template-url.md

@@ -13,8 +13,8 @@ First, it allows us to write our template in a separate HTML file. This gives us
 
 Second, because `templateURL` loads the template via Ajax at runtime, you don't need a build step in order to split up your files. This is convenient during development, but comes at a serious cost when you want to deploy it to production. Before HTTP/2 is universally supported, the number of HTTP requests is still probably the most critical factor in your app's initial load performance. Now imagine you use `templateURL` for every component in your app - the browser needs to perform dozens of HTTP requests before even being able to display anything! In case you don't know, most browsers limit the number of parallel requests it can perform to a single server. When you exceed that limit, your app's initial rendering will suffer for every extra round trip the browser has to wait for. Sure, there are build tools that can help you pre-register all those templates in `$templateCache` - but that shows us a build step is, in fact, inevitable for any serious frontend development.
 
-So, without `templateURL`, how do we deal with the development experience problem? Writing templates as inline JavaScript strings is terrible, faking templates with `<script type="x/template">` also feels like a hack. Well, maybe it's time to up the game a bit and use a proper module bundler like [Webpack](http://webpack.github.io/) or [Browserify](http://browserify.org/). It might seem daunting if you've never dealt with them before, but trust me it's worth it to take the leap. Proper modularization is a necessity if you want to build anything large and maintainable. More importantly, you get to write your [Vue components in a single file](http://vuejs.org/guide/single-file-components.html), with proper syntax highlighting and the extra benefits of custom pre-processors, hot-reloading, ES2015 by default, autoprefixing and scoped CSS, which makes the development experience 10 times better.
+So, without `templateURL`, how do we deal with the development experience problem? Writing templates as inline JavaScript strings is terrible, faking templates with `<script type="x/template">` also feels like a hack. Well, maybe it's time to up the game a bit and use a proper module bundler like [webpack](http://webpack.github.io/) or [Browserify](http://browserify.org/). It might seem daunting if you've never dealt with them before, but trust me it's worth it to take the leap. Proper modularization is a necessity if you want to build anything large and maintainable. More importantly, you get to write your [Vue components in a single file](http://vuejs.org/guide/single-file-components.html), with proper syntax highlighting and the extra benefits of custom pre-processors, hot-reloading, ES2015 by default, autoprefixing and scoped CSS, which makes the development experience 10 times better.
 
-Finally, Vue does allow you to [lazy load your components](http://vuejs.org/guide/components.html#Async-Components), and with Webpack it is trivially easy. Although this is only a concern when your initial bundle is so large that you are better off splitting it apart.
+Finally, Vue does allow you to [lazy load your components](http://vuejs.org/guide/components.html#Async-Components), and with webpack it is trivially easy. Although this is only a concern when your initial bundle is so large that you are better off splitting it apart.
 
 Think in components, not templates.

src/v2/cookbook/adding-instance-properties.md

@@ -158,7 +158,7 @@ So what are the alternatives?
 
 ### When Not Using a Module System
 
-In applications with **no** module system (e.g. via Webpack or Browserify), there's a pattern that's often used with _any_ JavaScript-enhanced frontend: a global `App` object.
+In applications with **no** module system (e.g. via webpack or Browserify), there's a pattern that's often used with _any_ JavaScript-enhanced frontend: a global `App` object.
 
 If what you want to add has nothing to do with Vue specifically, this may be a good alternative to reach for. Here's an example:
 

src/v2/cookbook/debugging-in-vscode.md

@@ -16,7 +16,7 @@ Install and create a project with the [vue-cli](https://github.com/vuejs/vue-cli
 
 ### Showing Source Code in the Chrome Devtools
 
-Before you can debug your Vue components from VS Code you need to update the generated Webpack config to build sourcemaps. We do this so that our debugger has a way to map the code within a compressed file back to its position in the original file. This ensures that you can debug an application even after your assets have been optimized by Webpack.
+Before you can debug your Vue components from VS Code you need to update the generated webpack config to build sourcemaps. We do this so that our debugger has a way to map the code within a compressed file back to its position in the original file. This ensures that you can debug an application even after your assets have been optimized by webpack.
 
 Go to `config/index.js` and find the `devtool` property. Update it to:
 

src/v2/cookbook/index.md

@@ -14,7 +14,7 @@ How is the cookbook different from the guide? Why is this necessary?
 
 * **Teaching JavaScript**: In the guide, we assume at least intermediate familiarity with ES5 JavaScript. For example, we won't explain how `Array.prototype.filter` works in a computed property that filters a list. In the cookbook however, essential JavaScript features (including ES6/2015+) can be explored and explained in the context of how they help us build better Vue applications.
 
-* **Exploring the Ecosystem**: For advanced features, we assume some ecosystem knowledge. For example, if you want to use single-file components in Webpack, we don't explain how to configure the non-Vue parts of the Webpack config. In the cookbook, we have the space to explore these ecosystem libraries in more depth - at least to the extent that is universally useful for Vue developers.
+* **Exploring the Ecosystem**: For advanced features, we assume some ecosystem knowledge. For example, if you want to use single-file components in webpack, we don't explain how to configure the non-Vue parts of the webpack config. In the cookbook, we have the space to explore these ecosystem libraries in more depth - at least to the extent that is universally useful for Vue developers.
 
 ## Cookbook Contributions
 

src/v2/guide/components-dynamic-async.md

@@ -214,18 +214,18 @@ Vue.component('async-example', function (resolve, reject) {
 })
 ```
 
-As you can see, the factory function receives a `resolve` callback, which should be called when you have retrieved your component definition from the server. You can also call `reject(reason)` to indicate the load has failed. The `setTimeout` here is for demonstration; how to retrieve the component is up to you. One recommended approach is to use async components together with [Webpack's code-splitting feature](https://webpack.js.org/guides/code-splitting/):
+As you can see, the factory function receives a `resolve` callback, which should be called when you have retrieved your component definition from the server. You can also call `reject(reason)` to indicate the load has failed. The `setTimeout` here is for demonstration; how to retrieve the component is up to you. One recommended approach is to use async components together with [webpack's code-splitting feature](https://webpack.js.org/guides/code-splitting/):
 
 ``` js
 Vue.component('async-webpack-example', function (resolve) {
-  // This special require syntax will instruct Webpack to
+  // This special require syntax will instruct webpack to
   // automatically split your built code into bundles which
   // are loaded over Ajax requests.
   require(['./my-async-component'], resolve)
 })
 ```
 
-You can also return a `Promise` in the factory function, so with Webpack 2 and ES2015 syntax you can do:
+You can also return a `Promise` in the factory function, so with webpack 2 and ES2015 syntax you can do:
 
 ``` js
 Vue.component(
@@ -246,7 +246,7 @@ new Vue({
 })
 ```
 
-<p class="tip">If you're a <strong>Browserify</strong> user that would like to use async components, its creator has unfortunately [made it clear](https://github.com/substack/node-browserify/issues/58#issuecomment-21978224) that async loading "is not something that Browserify will ever support." Officially, at least. The Browserify community has found [some workarounds](https://github.com/vuejs/vuejs.org/issues/620), which may be helpful for existing and complex applications. For all other scenarios, we recommend using Webpack for built-in, first-class async support.</p>
+<p class="tip">If you're a <strong>Browserify</strong> user that would like to use async components, its creator has unfortunately [made it clear](https://github.com/substack/node-browserify/issues/58#issuecomment-21978224) that async loading "is not something that Browserify will ever support." Officially, at least. The Browserify community has found [some workarounds](https://github.com/vuejs/vuejs.org/issues/620), which may be helpful for existing and complex applications. For all other scenarios, we recommend using webpack for built-in, first-class async support.</p>
 
 ### Handling Loading State
 

src/v2/guide/components-edge-cases.md

@@ -228,7 +228,7 @@ Then a `tree-folder-contents` component with this template:
 
 When you look closely, you'll see that these components will actually be each other's descendent _and_ ancestor in the render tree - a paradox! When registering components globally with `Vue.component`, this paradox is resolved for you automatically. If that's you, you can stop reading here.
 
-However, if you're requiring/importing components using a __module system__, e.g. via Webpack or Browserify, you'll get an error:
+However, if you're requiring/importing components using a __module system__, e.g. via webpack or Browserify, you'll get an error:
 
 ```
 Failed to mount component: template or render function not defined.
@@ -244,7 +244,7 @@ beforeCreate: function () {
 }
 ```
 
-Or alternatively, you could use Webpack's asynchronous `import` when you register the component locally:
+Or alternatively, you could use webpack's asynchronous `import` when you register the component locally:
 
 ``` js
 components: {

src/v2/guide/components-registration.md

@@ -72,7 +72,7 @@ This even applies to all subcomponents, meaning all three of these components wi
 
 ## Local Registration
 
-Global registration often isn't ideal. For example, if you're using a build system like Webpack, globally registering all components means that even if you stop using a component, it could still be included in your final build. This unnecessarily increases the amount of JavaScript your users have to download.
+Global registration often isn't ideal. For example, if you're using a build system like webpack, globally registering all components means that even if you stop using a component, it could still be included in your final build. This unnecessarily increases the amount of JavaScript your users have to download.
 
 In these cases, you can define your components as plain JavaScript objects:
 
@@ -109,7 +109,7 @@ var ComponentB = {
 }
 ```
 
-Or if you're using ES2015 modules, such as through Babel and Webpack, that might look more like:
+Or if you're using ES2015 modules, such as through Babel and webpack, that might look more like:
 
 ```js
 import ComponentA from './ComponentA.vue'
@@ -133,7 +133,7 @@ If you're not using a module system with `import`/`require`, you can probably sk
 
 ### Local Registration in a Module System
 
-If you're still here, then it's likely you're using a module system, such as with Babel and Webpack. In these cases, we recommend creating a `components`, with each component in its own file.
+If you're still here, then it's likely you're using a module system, such as with Babel and webpack. In these cases, we recommend creating a `components`, with each component in its own file.
 
 Then you'll need to import each component you'd like to use, before you locally register it. For example, in a hypothetical `ComponentB.js` or `ComponentB.vue` file:
 
@@ -184,7 +184,7 @@ Just to support relatively little markup in a template:
 </BaseButton>
 ```
 
-Fortunately, if you're using Webpack (or [Vue CLI 3+](https://github.com/vuejs/vue-cli), which uses Webpack internally), you can use `require.context` to globally register only these very common base components. Here's an example of the code you might use to globally import base components in your app's entry file (e.g. `src/main.js`):
+Fortunately, if you're using webpack (or [Vue CLI 3+](https://github.com/vuejs/vue-cli), which uses webpack internally), you can use `require.context` to globally register only these very common base components. Here's an example of the code you might use to globally import base components in your app's entry file (e.g. `src/main.js`):
 
 ```js
 import Vue from 'vue'