docs: Update casing from Webpack to webpack (#3655)

Following discussion in vercel/next.js#45560

docs/pages/blog/turbopack-benchmarks.mdx

@@ -1,7 +1,7 @@
 ---
 title: "Turbopack Performance Benchmarks"
 date: 2022/10/31
-description: "Benchmarking Turbopack performance against Vite and Webpack."
+description: "Benchmarking Turbopack performance against Vite and webpack."
 tag: "web development"
 ogImage: "/images/blog/turbopack-benchmarks/twitter-card.png"
 ---
@@ -33,7 +33,7 @@ import Date from "../../components/blog/Date";
 
 At [Next.js Conf](https://nextjs.org), [we announced](https://www.youtube.com/watch?v=NiknNI_0J48) our latest open-source project: Turbopack, an incremental bundler and build system optimized for JavaScript and TypeScript, written in Rust.
 
-The project began as an exploration to improve Webpack’s performance and create ways for it to more easily integrate with tooling moving forward. In doing so, the team realized that a greater effort was necessary. While we saw opportunities for better performance, the premise of a new architecture that could scale to the largest projects in the world was inspiring.
+The project began as an exploration to improve webpack’s performance and create ways for it to more easily integrate with tooling moving forward. In doing so, the team realized that a greater effort was necessary. While we saw opportunities for better performance, the premise of a new architecture that could scale to the largest projects in the world was inspiring.
 
 In this post, we will explore why Turbopack is so fast, how its incremental engine works, and benchmark it against existing approaches.
 
@@ -45,7 +45,7 @@ This does not work like traditional caching where you look up a result from a ca
 
 Instead, Turbopack skips work altogether for cached results and only recomputes affected parts of its internal dependency graph of functions. This makes updates independent of the size of the whole compilation, and eliminates the usual overhead of traditional caching.
 
-## Benchmarking Turbopack, Webpack, and Vite
+## Benchmarking Turbopack, webpack, and Vite
 
 We created a test generator that makes an application with a variable amount of modules to benchmark cold startup and file updating tasks. This generated app includes entries for these tools:
 
@@ -54,7 +54,7 @@ We created a test generator that makes an application with a variable amount of
 - Next.js 13 with Turbopack
 - Vite
 
-As the current state of the art, we are including [Vite](https://vitejs.dev/) along with Webpack-based [Next.js](https://nextjs.org) solutions. All of these toolchains point to the same generated component tree, assembling a [Sierpiński triangle](https://en.wikipedia.org/wiki/Sierpi%C5%84ski_triangle) in the browser, where every triangle is a separate module.
+As the current state of the art, we are including [Vite](https://vitejs.dev/) along with webpack-based [Next.js](https://nextjs.org) solutions. All of these toolchains point to the same generated component tree, assembling a [Sierpiński triangle](https://en.wikipedia.org/wiki/Sierpi%C5%84ski_triangle) in the browser, where every triangle is a separate module.
 
 <ThemedImageFigure
   borderRadius={false}
@@ -150,7 +150,7 @@ We report the linear regression slope of the data points as the target metric. T
     width: 1960
   }}
   captionSpacing={24}
-  caption="Turbopack, Next.js (Webpack), and Vite HMR by module count. Benchmark data generated from 16” MacBook Pro 2021, M1 Max, 32GB RAM, macOS 13.0.1 (22A400)."
+  caption="Turbopack, Next.js (webpack), and Vite HMR by module count. Benchmark data generated from 16” MacBook Pro 2021, M1 Max, 32GB RAM, macOS 13.0.1 (22A400)."
 />
 
 <a id="bench"/>
@@ -173,7 +173,7 @@ We report the linear regression slope of the data points as the target metric. T
 
 The takeaway: Turbopack performance is a function of **the size of an update**, not the size of an application.
 
-For more info, visit the comparison docs for [Vite](/pack/docs/comparisons/vite) and [Webpack](/pack/docs/comparisons/webpack).
+For more info, visit the comparison docs for [Vite](/pack/docs/comparisons/vite) and [webpack](/pack/docs/comparisons/webpack).
 
 #### Data
 
@@ -210,7 +210,7 @@ Visit the [Turbopack benchmark documentation](/pack/docs/benchmarks) to run the
 
 ## The future of the open-source Web
 
-Our team has taken the lessons from 10 years of Webpack, combined with the innovations in incremental computation from [Turborepo](/repo) and Google's Bazel, and created an architecture ready to support the coming decades of computing.
+Our team has taken the lessons from 10 years of webpack, combined with the innovations in incremental computation from [Turborepo](/repo) and Google's Bazel, and created an architecture ready to support the coming decades of computing.
 
 Our goal is to create a system of open source tooling that helps to build the future of the Web—powered by Turbopack. We are creating a reusable piece of architecture that will make both development and warm production builds faster for everyone.
 

docs/pages/pack/docs/benchmarks.mdx

@@ -13,7 +13,7 @@ We created a test generator that makes an application with a variable amount of
 - Next.js 13 with Turbopack
 - Vite
 
-As the current state of the art, we're including [Vite](https://vitejs.dev/) along with Webpack-based [Next.js](https://nextjs.org) solutions. All of these toolchains point to the same generated component tree, assembling a [Sierpiński triangle](https://en.wikipedia.org/wiki/Sierpi%C5%84ski_triangle) in the browser, where every triangle is a separate module.
+As the current state of the art, we're including [Vite](https://vitejs.dev/) along with webpack-based [Next.js](https://nextjs.org) solutions. All of these toolchains point to the same generated component tree, assembling a [Sierpiński triangle](https://en.wikipedia.org/wiki/Sierpi%C5%84ski_triangle) in the browser, where every triangle is a separate module.
 
 <ThemedImageFigure
   borderRadius={false}
@@ -115,7 +115,7 @@ We report the linear regression slope of the data points as the target metric. T
     width: 1960
   }}
   captionSpacing={24}
-  caption="Turbopack, Next.js (Webpack), and Vite HMR by module count. Benchmark data generated from 16” MacBook Pro 2021, M1 Max, 32GB RAM, macOS 13.0.1 (22A400)."
+  caption="Turbopack, Next.js (webpack), and Vite HMR by module count. Benchmark data generated from 16” MacBook Pro 2021, M1 Max, 32GB RAM, macOS 13.0.1 (22A400)."
 />
 
 <a id="bench"/>
@@ -138,7 +138,7 @@ We report the linear regression slope of the data points as the target metric. T
 
 The takeaway from these benchmarks: Turbopack performance is a function of **the size of an update**, not the size of an application.
 
-We're excited by Turbopack's performance, but we also expect to make further speed improvements for both small and large applications in the future. For more info, visit the comparison docs for [Vite](/pack/docs/comparisons/vite) and [Webpack](/pack/docs/comparisons/webpack).
+We're excited by Turbopack's performance, but we also expect to make further speed improvements for both small and large applications in the future. For more info, visit the comparison docs for [Vite](/pack/docs/comparisons/vite) and [webpack](/pack/docs/comparisons/webpack).
 
 #### Data
 

docs/pages/pack/docs/comparisons/webpack.mdx

@@ -1,31 +1,31 @@
 ---
-title: Turbopack vs. Webpack
-description: Compare Turbopack vs. Webpack
+title: Turbopack vs. webpack
+description: Compare Turbopack vs. webpack
 ---
 
 import { DocsBenchmarksGraph } from '../../../../components/pages/pack-home/DocsBenchmarksGraph';
 import { DocsBenchmarkStat } from '../../../../components/pages/pack-home/DocsBenchmarkStat';
 import BenchmarksCallout from './BenchmarksCallout';
 
-# Comparing Turbopack and Webpack
+# Comparing Turbopack and webpack
 
-Webpack has been downloaded over 3 billion times, making it today's most common JavaScript bundler. However, we found that we'd hit the limits of what it could do with its JavaScript-based architecture.
+webpack has been downloaded over 3 billion times, making it today's most common JavaScript bundler. However, we found that we'd hit the limits of what it could do with its JavaScript-based architecture.
 
-We've built Turbopack as the successor of Webpack: much **faster**, but just as **flexible and extensible**.
+We've built Turbopack as the successor of webpack: much **faster**, but just as **flexible and extensible**.
 
 <BenchmarksCallout />
 
 ## Speed
 
-Turbopack's incremental architecture outstrips Webpack's speed on several key metrics.
+Turbopack's incremental architecture outstrips webpack's speed on several key metrics.
 
 ### Dev server startup time
 
-The main problem we found with Webpack was development server startup time. If you end up importing a lot of modules in a certain page and open that page in your browser, the initial compile will take a few seconds. If you change routes in your development environment, you have to wait for a similar compile again for your new page.
+The main problem we found with webpack was development server startup time. If you end up importing a lot of modules in a certain page and open that page in your browser, the initial compile will take a few seconds. If you change routes in your development environment, you have to wait for a similar compile again for your new page.
 
 We designed Turbopack to be as lazy as possible, only doing work when it's requested. In a dev server, this means on incoming requests we do **exactly the work the user asked for**. No more unnecessary bundling of on demand loaded code before the user needs it. You can learn more in our [core concepts docs](/pack/docs/core-concepts#compiling-by-request).
 
-This means that Turbopack's dev server starts up much faster than Webpack. Next.js 12, which uses Webpack under the hood, can start up a build server on a 1,000 module application in <DocsBenchmarkStat stat="next12-cold-1000" />. Turbopack starts up in <DocsBenchmarkStat stat="turbopack-cold-1000" /> - **<DocsBenchmarkStat stat="turbopack-cold-vs-next12" /> faster**.
+This means that Turbopack's dev server starts up much faster than webpack. Next.js 12, which uses webpack under the hood, can start up a build server on a 1,000 module application in <DocsBenchmarkStat stat="next12-cold-1000" />. Turbopack starts up in <DocsBenchmarkStat stat="turbopack-cold-1000" /> - **<DocsBenchmarkStat stat="turbopack-cold-vs-next12" /> faster**.
 
 <DocsBenchmarksGraph category="cold" bars={[
   {
@@ -34,18 +34,18 @@ This means that Turbopack's dev server starts up much faster than Webpack. Next.
     key: 'next13'
   },
   {
-    label: 'Webpack',
+    label: 'webpack',
     key: 'next12',
   }
 ]} />
 
 ### Code updates
 
-As we continued to optimize Webpack, we found a performance ceiling on how much faster we could make Fast Refresh. With around 2,000 components, the best number we could produce was 500ms. This mark was a tremendous feat in Next.js 12. Previously, that process would have taken around 10 seconds.
+As we continued to optimize webpack, we found a performance ceiling on how much faster we could make Fast Refresh. With around 2,000 components, the best number we could produce was 500ms. This mark was a tremendous feat in Next.js 12. Previously, that process would have taken around 10 seconds.
 
 With Turbopack, we achieved the goal we were aiming for: Fast Refresh performance that stays near-constant, no matter your application size. Instead of scaling with your application size, it scales based on the size of the _changes made_.
 
-In a 1,000 module application, Turbopack can react to file changes **<DocsBenchmarkStat stat="turbopack-update-vs-next12" /> faster** than Webpack. In a 30,000 module application, this is **<DocsBenchmarkStat stat="turbopack-update-vs-next12-30000" /> faster**.
+In a 1,000 module application, Turbopack can react to file changes **<DocsBenchmarkStat stat="turbopack-update-vs-next12" /> faster** than webpack. In a 30,000 module application, this is **<DocsBenchmarkStat stat="turbopack-update-vs-next12-30000" /> faster**.
 
 <DocsBenchmarksGraph category="file_change" bars={[
   {
@@ -54,13 +54,13 @@ In a 1,000 module application, Turbopack can react to file changes **<DocsBenchm
     key: 'next13'
   },
   {
-    label: 'Webpack',
+    label: 'webpack',
     key: 'next12',
   }
 ]} />
 
 ## Extensibility
 
-Webpack has an extraordinary collection of [plugins](https://webpack.js.org/plugins/) to customize its behavior. Composing plugins lets you create custom toolchains which can support a huge variety of bundler features.
+webpack has an extraordinary collection of [plugins](https://webpack.js.org/plugins/) to customize its behavior. Composing plugins lets you create custom toolchains which can support a huge variety of bundler features.
 
-In its alpha state, Turbopack cannot currently be configured with plugins. In the future, we plan to make Turbopack just as extensible as Webpack - though likely with an altered API.
+In its alpha state, Turbopack cannot currently be configured with plugins. In the future, we plan to make Turbopack just as extensible as webpack - though likely with an altered API.

docs/pages/pack/docs/features/environment-variables.mdx

@@ -26,4 +26,4 @@ Not only that, but Turbopack will live reload when these values change. Restarti
 
 Environment variables will be injected into `process.env`. For instance, `DATABASE_URL` will be on `process.env.DATABASE_URL`.
 
-This follows the tradition of Node.js, Webpack 5 and Next.js 12, which each use `process.env` for variable injection.
+This follows the tradition of Node.js, webpack 5 and Next.js 12, which each use `process.env` for variable injection.

docs/pages/pack/docs/features/static-assets.mdx

@@ -14,7 +14,7 @@ import audio from './audio.wav'
 
 ### Next.js
 
-In Webpack and some other frameworks, importing an image returns a string containing that image's URL.
+In webpack and some other frameworks, importing an image returns a string containing that image's URL.
 
 ```ts
 import img from './img.png';

docs/pages/pack/docs/index.mdx

@@ -10,13 +10,13 @@ import FullTurboCTA from "../../../components/FullTurboCTA";
 
 # Getting Started with Turbopack
 
-Turbopack is an incremental bundler optimized for JavaScript and TypeScript, written in Rust by the creators of Webpack and [Next.js](https://nextjs.org/) at [Vercel](https://vercel.com/).
+Turbopack is an incremental bundler optimized for JavaScript and TypeScript, written in Rust by the creators of webpack and [Next.js](https://nextjs.org/) at [Vercel](https://vercel.com/).
 
-On large applications Turbopack updates 10x faster than Vite and 700x faster than Webpack. For the biggest applications the difference grows even more stark with updates up to 20x faster than Vite.
+On large applications Turbopack updates 10x faster than Vite and 700x faster than webpack. For the biggest applications the difference grows even more stark with updates up to 20x faster than Vite.
 
 The secret to Turbopack's performance is twofold: highly optimized machine code and a low-level incremental computation engine that enables caching down to the level of individual functions. Once Turbopack performs a task it never does it again.
 
-Our team has taken the lessons from 10 years of Webpack, combined with the innovations in incremental computation from [Turborepo](/repo) and Google's Bazel, and created an architecture ready to support the coming decades of computing.
+Our team has taken the lessons from 10 years of webpack, combined with the innovations in incremental computation from [Turborepo](/repo) and Google's Bazel, and created an architecture ready to support the coming decades of computing.
 
 <Callout type="error">
     Turbopack is currently in <strong>alpha</strong>. It is not yet ready for production use. We appreciate your support and feedback as we work to make it ready for everyone.

docs/pages/pack/docs/migrating-from-webpack.mdx

@@ -1,24 +1,24 @@
 ---
-title: Migrate from Webpack to Turbopack
-description: Learn about how to migrate from Webpack to its Rust-powered successor, Turbopack.
+title: Migrate from webpack to Turbopack
+description: Learn about how to migrate from webpack to its Rust-powered successor, Turbopack.
 ---
 
-# Migrating from Webpack to Turbopack
+# Migrating from webpack to Turbopack
 
-We're planning Turbopack as the successor to Webpack. In the future, we plan to give Turbopack all the tools needed to support your Webpack app.
+We're planning Turbopack as the successor to webpack. In the future, we plan to give Turbopack all the tools needed to support your webpack app.
 
-Currently, migrating to Turbopack from Webpack is **not yet possible**. In the future, we're planning to offer a smooth migration path for all Webpack users to join the Turbopack future.
+Currently, migrating to Turbopack from webpack is **not yet possible**. In the future, we're planning to offer a smooth migration path for all webpack users to join the Turbopack future.
 
-## Will it be compatible with Webpack's API?
+## Will it be compatible with webpack's API?
 
-Webpack has a huge API. It's extremely flexible and extensible, which is a big reason why it's so popular.
+webpack has a huge API. It's extremely flexible and extensible, which is a big reason why it's so popular.
 
-We're planning on making Turbopack very flexible and extensible, but we're **not planning 1:1 compatibility with Webpack**. This lets us make choices which improve on Webpack's API, and lets us optimize for speed and efficiency.
+We're planning on making Turbopack very flexible and extensible, but we're **not planning 1:1 compatibility with webpack**. This lets us make choices which improve on webpack's API, and lets us optimize for speed and efficiency.
 
-## Will we be able to use Webpack plugins?
+## Will we be able to use webpack plugins?
 
-Webpack plugins are a crucial part of Webpack's ecosystem. They let you customize your toolchain, giving you low-level tools to maximize your productivity.
+webpack plugins are a crucial part of webpack's ecosystem. They let you customize your toolchain, giving you low-level tools to maximize your productivity.
 
-Since we're not offering 1:1 API compatibility, most Webpack plugins won't work out of the box with Turbopack.
+Since we're not offering 1:1 API compatibility, most webpack plugins won't work out of the box with Turbopack.
 
-However, we're working on porting several of the most popular Webpack plugins to Turbopack.
+However, we're working on porting several of the most popular webpack plugins to Turbopack.

docs/pages/pack/docs/roadmap.mdx

@@ -24,9 +24,9 @@ In the future, we plan to persist this cache to the file system, to speed up Tur
 
 Once persisting to the file system is working, we can build the next logical step: persisting to a remote cache. With Turborepo, we've already built [remote caching](/repo/docs/core-concepts/remote-caching) on Vercel. In the future, you'll be able to _share_ Turbopack's hyper-granular cache across your whole team, using the Vercel Remote Cache.
 
-## Migration for Webpack users
+## Migration for webpack users
 
-To learn more about our future plans for Webpack integration, check out our [Migrating from Webpack](/pack/docs/migrating-from-webpack) page.
+To learn more about our future plans for webpack integration, check out our [Migrating from webpack](/pack/docs/migrating-from-webpack) page.
 
 ## Fusion with Turborepo