fix(docs): brand name Webpack to webpack (#22906)

docs/blog/2017-02-21-1-0-progress-update-where-came-from-where-going/index.md

@@ -58,7 +58,7 @@ It wraps three of the most popular web app tools into a cohesive website
 framework:
 
 - [React](https://reactjs.org/) from Facebook for building UIs
-- [Webpack](https://webpack.js.org/) for bundling JavaScript and CSS
+- [webpack](https://webpack.js.org/) for bundling JavaScript and CSS
 - [GraphQL](https://graphql.org/) from Facebook for declarative data queries
 
 While designing Gatsby, I wanted a synthesis of two of my favorite developer

docs/blog/2017-09-26-embracing-graphql/index.md

@@ -21,7 +21,7 @@ Gatsby at the time was still pre-1.0 but its workflow met my needs. I loved that
 I could drop my existing Markdown files into a `pages` directory and Gatsby
 would do the rest.
 
-Webpack loader —> React.js wrapper component —> static HTML page. Done.
+webpack loader —> React.js wrapper component —> static HTML page. Done.
 
 Well...done until I read this
 [GitHub Issue](https://github.com/gatsbyjs/gatsby/issues/420) … "New GraphQL

docs/blog/2017-10-03-smartive-goes-gatsby/index.md

@@ -36,7 +36,7 @@ the major drawbacks at that time were:
 - Pulling in external resources, such as blog posts, was quite unhandy and
   sometimes even impossible
 - Build process optimization was almost impossible and in our case resulted in a
-  Webpack setup on top of Wintersmith which was not really maintainable
+  webpack setup on top of Wintersmith which was not really maintainable
 
 ### React to the Rescue!
 

docs/blog/2017-10-05-portfolio-site-gatsby-wordpress/index.md

@@ -33,7 +33,7 @@ video on
 [GatsbyJS](/) is a static site generator, similar to Jekyll, however it is
 written using [React](https://reactjs.org/) and allows you to write your pages
 as React components! It is somewhat similar to create-react-app where almost all
-the scary Webpack config has been abstracted away from you and everything is
+the scary webpack config has been abstracted away from you and everything is
 setup ready to go, so you can get to the important stuff like...building the
 site! (If you are a fan of React and not convinced, the
 [React website/docs](https://reactjs.org/) were just released using Gatsby!)

docs/blog/2017-11-06-migrate-hugo-gatsby/index.md

@@ -39,7 +39,7 @@ to classical CMS comparing to Gatsby workflows.
 As it's an older ecosystem, when you need a ready plugin or a theme for quick
 gratification, it's more likely to find something ready online for Hugo.
 
-Gatsby, on the other hand, is based on React, GraphQL, Webpack and its way of
+Gatsby, on the other hand, is based on React, GraphQL, webpack and its way of
 thinking is closer to how a developer would approach the problems from a
 single-page-application point of view.
 
@@ -59,7 +59,7 @@ For me, using Gatsby is
 [valuable learning experience](https://kalinchernev.github.io/learn-gatsbyjs)
 and it has also been so easy to work with, it feels "unfair". For example, the
 plugin system of Gatsby keeps me sane and productive, even in cases where I know
-only the briefest overview concepts of Webpack. Without Gatsby, I might have
+only the briefest overview concepts of webpack. Without Gatsby, I might have
 spent hours and days configuring what Gatsby provides out of the box.
 
 Last, but not least, the biggest benefit of using Gatsby compared to Hugo, is

docs/blog/2017-11-09-why-i-created-my-blog-with-gatsby-and-contentful/index.md

@@ -190,11 +190,11 @@ That would give us the best of both worlds, right?
 Well, a guy named [Kyle Mathews](https://github.com/KyleAMathews) already
 thought of that and created Gatsby.js.
 
-## Generating static websites with React and Webpack
+## Generating static websites with React and webpack
 
 A little disclaimer: I absolutely love React, so, when I first learned that
 there were some emerging Static Site Generators who leveraged only React and
-Webpack, I knew that I had to try at least one of them for the new upcoming blog
+webpack, I knew that I had to try at least one of them for the new upcoming blog
 I was planning to build. These projects were [Gatsby.js](https://gatsbyjs.org/)
 and [Phenomic](https://phenomic.io/), and both were still quite young back then,
 neither of them having reached the 1.0 release yet.
@@ -238,7 +238,7 @@ was completely mindblown.
 
 https://giphy.com/gifs/tim-and-eric-mind-blown-EldfH1VJdbrwY
 
-Not only did it have all the standard goodness of a typical React/Webpack static
+Not only did it have all the standard goodness of a typical React/webpack static
 site generator (CSS Modules, PostCSS, Hot Reloading, etc), but more importantly,
 it integrated an incredibly ingenious GraphQL layer which allowed the developer
 to query and fetch data from practically everywhere on the web!

docs/blog/2017-12-07-taking-gatsby-for-a-spin/index.md

@@ -29,7 +29,7 @@ Gatsby was my first introduction to [GraphQL](https://graphql.org/learn/) and I'
 
 With an eye on the future, Gatsby already implements lots of Googles so called '**P**ush, **R**ender **P**re-Cache and **L**azy-load pattern (PRPL, I'm not sure if that acronym will catch on). Gatsby takes care of the pre-loading and code-splitting, which makes browsing around Gatsby sites an insanely fast experience. PRPL + the gatsby offline plugin mean that your site will be considered a PWA, will load insanely fast on any device and scores great in Google lighthouse. Read more on [PRPL](/docs/prpl-pattern/).
 
-### Webpack and Plugins
+### webpack and Plugins
 
 Can you say React without webpack? I can hardly say `hello world` without webpack anymore, although I'm still not sure how to configure it right on the first go. Gatsby comes with an extensive webpack configuration and you don't really need to touch if you don't want to. If you do, you can modify and add to the default configuration with a plugin or in the `gatsby-node` file. There's already a great range of plugins so most likely any webpack tweak is a plugin install away. With all the plenty of good examples, it’s often straightforward to write your own plugin too.
 

docs/blog/2018-03-29-migration-from-wordpress-to-gatsby/index.md

@@ -56,7 +56,7 @@ There are many factors to consider. Maturity is important as it means a big comm
 
 ### Modern technologies
 
-Gatsby is built with a lot of interesting technologies. If you are a frontend developer, you'll probably be familiar with most of these, so adoption should be quick. If not, it gives you chance to learn a lot of interesting stuff. Gatsby is powered by React. You'll be able to nicely structure your project to components and use all the existing React components there not specifically developed for Gatsby. For styling, you can attach plain old CSS stylesheet, but Gatsby offers many more choices like Sass, Glamor, Styled Components, Stylus, Less or Styled JSX. Gatsby is built on top of Webpack. And it can generate offline-ready Progressive Web App and uses GraphQL for querying data.
+Gatsby is built with a lot of interesting technologies. If you are a frontend developer, you'll probably be familiar with most of these, so adoption should be quick. If not, it gives you chance to learn a lot of interesting stuff. Gatsby is powered by React. You'll be able to nicely structure your project to components and use all the existing React components there not specifically developed for Gatsby. For styling, you can attach plain old CSS stylesheet, but Gatsby offers many more choices like Sass, Glamor, Styled Components, Stylus, Less or Styled JSX. Gatsby is built on top of webpack. And it can generate offline-ready Progressive Web App and uses GraphQL for querying data.
 
 ### Data sources and GraphQL
 
@@ -68,7 +68,7 @@ What's really powerful is using GraphQL as the query language. Because when quer
 
 ### Performance
 
-One of the Gatsby's greatest advantages is performance. I mean - performance on top of what you get by switching to a static site generator. Since Gatsby uses Webpack, it allows code splitting by route. That means when accessing a page on your site, the client will download only code and resources necessary for the current sub-page and not the whole bundle. When navigating to another route, it will just fetch what's new. Gatsby also sticks to the Progressive Web App standard. That means your site can behave as a native-like app on mobile and work with a poor connection or even offline. What's more, Gatsby utilizes the [PRPL Pattern](https://developers.google.com/web/fundamentals/performance/prpl-pattern/). That means first push critical resources over HTTP/2 to the client, which is faster than waiting for the browser to download HTML first, parse it and then request additional stylesheets, scripts and resources linked in the HTML. Gatsby first renders static HTML version of the initial route to minimize time-to-interactive. Then in the background, it loads the bundle and initializes a Single Page App. It then starts to pre-fetch resources for the routes linked to the initial page so additional navigation within your site is blazing fast and without reload.
+One of the Gatsby's greatest advantages is performance. I mean - performance on top of what you get by switching to a static site generator. Since Gatsby uses webpack, it allows code splitting by route. That means when accessing a page on your site, the client will download only code and resources necessary for the current sub-page and not the whole bundle. When navigating to another route, it will just fetch what's new. Gatsby also sticks to the Progressive Web App standard. That means your site can behave as a native-like app on mobile and work with a poor connection or even offline. What's more, Gatsby utilizes the [PRPL Pattern](https://developers.google.com/web/fundamentals/performance/prpl-pattern/). That means first push critical resources over HTTP/2 to the client, which is faster than waiting for the browser to download HTML first, parse it and then request additional stylesheets, scripts and resources linked in the HTML. Gatsby first renders static HTML version of the initial route to minimize time-to-interactive. Then in the background, it loads the bundle and initializes a Single Page App. It then starts to pre-fetch resources for the routes linked to the initial page so additional navigation within your site is blazing fast and without reload.
 
 Gatsby also works great with images, which are usually a big hit to site's performance. Based on the screen size and resolution of the client device, it will serve appropriate image size. It supports WebP and can convert your jpegs to progressive jpegs. While the images are loading, it will reserve the space required by the image, so the content of the page is not 'hopping' after image loads. It also replaces the image with a blurred version or monochromatic SVG until it loads - similar to what Medium uses.
 

docs/blog/2018-05-11-six-reasons-i-chose-gatsby/index.md

@@ -16,7 +16,7 @@ I've been working with React for the better part of 3.5 years. I know it. I'm ef
 
 ## #2: An extensive, well-architected plugin system
 
-One of the first things about Gatsby that impressed me was its plugin system. Like many other OSS tools such as Webpack and Babel, much of the power of Gatsby is provided by plugins. And that's a good thing. Its plugin architecture allows for incredibly deep integrations into almost every aspect of Gatsby: build configuration, data extraction and transformation, the build process, the browser at runtime, etc. This system has allowed not only the core Gatsby team to create powerful plugins, but the community to create equally powerful plugins as well. I've even tried my hand at [writing one](https://github.com/raygesualdo/gatsby-plugin-settings) (quite successfully, I might add). If there's a task you're looking to accomplish with Gatsby, odds are there is already a plugin for it. And if not, there's [plenty of documentation](/docs/plugins/) to help you get started writing one.
+One of the first things about Gatsby that impressed me was its plugin system. Like many other OSS tools such as webpack and Babel, much of the power of Gatsby is provided by plugins. And that's a good thing. Its plugin architecture allows for incredibly deep integrations into almost every aspect of Gatsby: build configuration, data extraction and transformation, the build process, the browser at runtime, etc. This system has allowed not only the core Gatsby team to create powerful plugins, but the community to create equally powerful plugins as well. I've even tried my hand at [writing one](https://github.com/raygesualdo/gatsby-plugin-settings) (quite successfully, I might add). If there's a task you're looking to accomplish with Gatsby, odds are there is already a plugin for it. And if not, there's [plenty of documentation](/docs/plugins/) to help you get started writing one.
 
 ## #3: The data fetching layer
 

docs/blog/2018-06-08-life-after-layouts/index.md

@@ -120,7 +120,7 @@ Removing layouts isn't the only improvement coming in Gatsby V2. We're really ex
 https://twitter.com/gatsbyjs/status/974507205121617920
 
 - We can now add GraphQL queries to any component in our app (not just page components) using [`StaticQuery`](/docs/static-query/)
-- Upgraded to the latest versions of React, Babel, Webpack, and other libraries Gatsby depends on
+- Upgraded to the latest versions of React, Babel, webpack, and other libraries Gatsby depends on
 - Better support for CSS inlining and splitting, which will boost performance
 
 For a full list of what's new, check out our [V2 migration guide](/docs/migrating-from-v1-to-v2/) and [_What’s New in Gatsby V2?_](/blog/2018-06-16-announcing-gatsby-v2-beta-launch/).

docs/blog/2018-06-18-why-narative-loves-gatsby/index.md

@@ -29,7 +29,7 @@ Great performance out-of-the-box is a huge win. Our team does not have to focus
 
 ## Developing with Gatsby is fast, really fast
 
-Gatsby does not only allow us to deliver fast websites, it has also sped up our development time. The developer experience is another focus of the team behind Gatsby - and it shows. Features such as live reload are ready to go at when you start a new project. There's no need to setup a custom Webpack configuration as the basics are completed for you. Building your website and deploying is also carefully thought out by Gatsby and often requires running a single command and using one of the many integrations for hosting. Furthermore, the documentation is comprehensive and has plenty of content from introductory guides to complex use cases. This has been amazing for training and on boarding new members of our team, especially if they're already familiar with React.
+Gatsby does not only allow us to deliver fast websites, it has also sped up our development time. The developer experience is another focus of the team behind Gatsby - and it shows. Features such as live reload are ready to go at when you start a new project. There's no need to setup a custom webpack configuration as the basics are completed for you. Building your website and deploying is also carefully thought out by Gatsby and often requires running a single command and using one of the many integrations for hosting. Furthermore, the documentation is comprehensive and has plenty of content from introductory guides to complex use cases. This has been amazing for training and on boarding new members of our team, especially if they're already familiar with React.
 
 ## Separation between view and data layers
 

docs/blog/2018-2-7-jam-out-your-blog/index.md

@@ -28,7 +28,7 @@ https://giphy.com/gifs/tom-cruise-top-gun-WDtCGLCXBAgow
 ### Like Josh’s requirements, my list includes:
 
 - **Speed** - this includes development, website performance, and deployment
-- **Development Experience** - I want to use React and Webpack
+- **Development Experience** - I want to use React and webpack
 - **Maintainability** - ease with which anyone can create, update and delete posts
 - **Scalability** - need to make sure that performance is not hindered by a growing needs
 - **Lean** - simplify the tools and services use to a bare minimum
@@ -111,7 +111,7 @@ Let’s summarize where we are and why [Netlify](https://www.netlify.com/) will
 
 [x] Speed - this includes development, website performance, and deployment
 
-[x] Development Experience - I want to use React and Webpack
+[x] Development Experience - I want to use React and webpack
 
 [x] Maintainability - ease with which anyone can create, update and delete posts
 

docs/blog/2019-03-05-dot-org-messaging-survey/index.md

@@ -89,7 +89,7 @@ At companies, 43% said this was crucial. “It's f\*cking fast to dev with, ulti
 Many people still marked these values as crucial things that Gatsby gives them. Just not as many people marked these as crucial as the top three values listed above, though we know they are still crucial to some! Here they are:
 
 - Best of both worlds: Gatsby empowers creators to build web experiences that leverage the benefits of both static sites (SEO friendly, fast) and web applications (dynamic data, interactive) — simultaneously.
-- Build with modern tools: Leverage the power of the latest web technologies including React, Webpack, GraphQL, modern JavaScript, and more.
+- Build with modern tools: Leverage the power of the latest web technologies including React, webpack, GraphQL, modern JavaScript, and more.
 - Bring your own content: Gatsby consolidates your data (source agnostic- CMS, static files, database, etc.) into a single, predictable, queryable layer.
 - Low to no hosting costs: Gatsby eliminates the need for traditional hosting costs because the site is hosted on the edge (Content Delivery Network).
 - Instantly scalable: No servers and no databases to manage with a website that never goes down because it’s built on the edge, instantly scaling for traffic spikes.

docs/blog/2019-04-02-behind-the-scenes-what-makes-gatsby-great/index.md

@@ -195,7 +195,7 @@ export default function Contact() {
 
 Pretty vanilla looking component! We are rendering a `form` with some validation and functionality provided by the excellent libraries [`yup`](https://www.npmjs.com/package/yup) and [`Formik`](https://github.com/jaredpalmer/formik). The likelihood that these libraries are used in _all_ routes in our application is unlikely--yet this is traditionally the approach that many take with bundling their client-side JS libraries. This means that even if a particular route (e.g. `/about`) is _not using_ certain libraries that they will still likely be included in a monolithic JavaScript bundle containing all dependencies. However--Gatsby, your friendly _web app compiler_, is a little smarter!
 
-We use code-splitting (enabled via our internalized dependency [Webpack](https://webpack.js.org)), and in particular, our approach prioritizes app-level dependencies (libraries used by the majority or all routes) coupled with route-based code splitting for dependencies that are likely only used on a particular route. To more fully understand this, let's take a look at a sample structure produced by our build process: `gatsby build`.
+We use code-splitting (enabled via our internalized dependency [webpack](https://webpack.js.org)), and in particular, our approach prioritizes app-level dependencies (libraries used by the majority or all routes) coupled with route-based code splitting for dependencies that are likely only used on a particular route. To more fully understand this, let's take a look at a sample structure produced by our build process: `gatsby build`.
 
 ```text:title=public/
 ├── 404
@@ -232,7 +232,7 @@ are bundled on _every_ route because they are used on _every_ route.
 
 Consider the output of [`webpack-bundle-analyzer`](https://github.com/webpack-contrib/webpack-bundle-analyzer), which makes this even clearer.
 
-![Webpack Bundle Analyzer](./images/bundle-analyzer.png)
+![webpack Bundle Analyzer](./images/bundle-analyzer.png)
 
 ### `component---{route-name}-{unique-hash}.js`
 
@@ -317,7 +317,7 @@ To tie it all together, the build process produces a `contact/index.html` file c
 
 This is an optimized, HTML representation of the React component at `src/pages/contact.js` containing the **minimal** resources required for the page. Our users only load the resources they need for every single route. No more, no less. 🔥
 
-_Want to dive deeper? Much of this is encapsulated in our internal [Webpack config](https://github.com/gatsbyjs/gatsby/blob/master/packages/gatsby/src/utils/webpack.config.js)_
+_Want to dive deeper? Much of this is encapsulated in our internal [webpack config](https://github.com/gatsbyjs/gatsby/blob/master/packages/gatsby/src/utils/webpack.config.js)_
 
 ## Modern APIs in Gatsby