docs: fix assorted typos across docs

Author: Rupendra0

src/content/blog/2020-10-10-webpack-5-release.mdx

@@ -587,7 +587,7 @@ This is true in general, but might not be always true during webpack or plugin d
 
 Targets that only allow to startup a single file (like node, WebWorker, electron main) now supports loading the dependent pieces required for bootstrapping automatically by the runtime.
 
-This allows using `opimization.splitChunks` for these targets with `chunks: "all"` and also `optimization.runtimeChunk`
+This allows using `optimization.splitChunks` for these targets with `chunks: "all"` and also `optimization.runtimeChunk`
 
 Note that with targets where chunk loading is async, this makes initial evaluation async too. This can be an issue when using `output.library`, since the exported value is a Promise now.
 
@@ -1293,7 +1293,7 @@ These dependencies are cheaper to process and webpack uses them when possible
 - `Compilation.addModuleDependencies` removed
 - `Compilation.prefetch` removed
 - `Compilation.hooks.beforeHash` is now called after the hashes of modules are created
-  - **MIGRATION**: Use `Compiliation.hooks.beforeModuleHash` instead
+  - **MIGRATION**: Use `Compilation.hooks.beforeModuleHash` instead
 - `Compilation.applyModuleIds` removed
 - `Compilation.applyChunkIds` removed
 - `Compiler.root` added, which points to the root compiler
@@ -1392,7 +1392,7 @@ These dependencies are cheaper to process and webpack uses them when possible
 - `ExternalModule.external` removed
 - `HarmonyInitDependency` removed
 - `Dependency.getInitFragments` deprecated
-  - **MIGRATION**: Use `apply` `initFragements` instead
+  - **MIGRATION**: Use `apply` `initFragments` instead
 - DependencyReference now takes a function to a module instead of a Module
 - HarmonyImportSpecifierDependency.redirectedId removed
   - **MIGRATION**: Use `setId` instead

src/content/blog/2020-12-08-roadmap-2021.mdx

@@ -160,7 +160,7 @@ We have to check whether it's possible to avoid potential conflicts.
 #### HTML as entrypoint
 
 Following Parcels example, we also want to support HTML natively as entrypoints.
-Supporting that would be inline with the goal as web app optimizer, as web apps unusally start with a HTML.
+Supporting that would be inline with the goal as web app optimizer, as web apps usually start with an HTML document.
 It is also a huge developer experience improvement for beginners as many things can be inferred from the HTML.
 
 Being in control of the generated HTML does also allow to optimize more aggressively by default.
@@ -182,7 +182,7 @@ This is something we want to look into for webpack, but also for terser, which i
 Node.js 14 has added support for the `exports` field in package.json to allow to define entrypoints of a package.
 Webpack 5 followed this, and even added additional conditions like `production/development`.
 
-Shortly after that Node.js made further additionals to that, e.g. they also added an `imports` field for private imports.
+Shortly after that Node.js made further additions to that, e.g. they also added an `imports` field for private imports.
 
 That's something we also want to add.
 

src/content/configuration/devtool.mdx

@@ -74,7 +74,7 @@ T> Instead of using the `devtool` option you can also use `SourceMapDevToolPlugi
 | `hidden-*` addition     | no reference to the SourceMap added. When SourceMap is not deployed, but should still be generated, e. g. for error reporting purposes.                                                                                                                                                                           |
 | `nosources-*` addition  | source code is not included in SourceMap. This can be useful when the original files should be referenced (further config options needed).                                                                                                                                                                        |
 
-T> We expect a certain pattern when validate devtool name, pay attention and dont mix up the sequence of devtool string. The pattern is: `[inline-|hidden-|eval-][nosources-][cheap-[module-]]source-map`.
+T> We expect a certain pattern when validate devtool name, pay attention and don't mix up the sequence of devtool string. The pattern is: `[inline-|hidden-|eval-][nosources-][cheap-[module-]]source-map`.
 
 Some of these values are suited for development and some for production. For development you typically want fast Source Maps at the cost of bundle size, but for production you want separate Source Maps that are accurate and support minimizing.
 

src/content/configuration/extending-configurations.mdx

@@ -106,7 +106,7 @@ module.exports = {
 };
 ```
 
-## Overridding Configurations
+## Overriding Configurations
 
 You can override configurations from the extended configuration by passing the same property in the configuration that extends it.
 

src/content/configuration/output.mdx

@@ -1288,7 +1288,7 @@ module.exports = _entry_return_;
 require('MyLibrary').doSomething();
 ```
 
-If we specify `output.library.name` with `type: commmonjs2`, the return value of your entry point will be assigned to the `module.exports.[output.library.name]`.
+If we specify `output.library.name` with `type: commonjs2`, the return value of your entry point will be assigned to the `module.exports.[output.library.name]`.
 
 T> Wondering the difference between CommonJS and CommonJS2 is? While they are similar, there are some subtle differences between them that are not usually relevant in the context of webpack. (For further details, please [read this issue](https://github.com/webpack/webpack/issues/1114).)
 

src/content/guides/getting-started.mdx

@@ -201,7 +201,7 @@ Now, since we'll be bundling our scripts, we have to update our `index.html` fil
  </html>
 ```
 
-T> A couple other script loading strategies exist. Deferred loading is one such alternative to the above, where instead scripts are consolidated into the `<head>` and are given the `defer` attribute. This strategy downloads the external script resource(s) in parallel with document parsing, and will execute the scripts in order of document appearance after parsing has finished. This is in contrast to the above, in which the parser pauses to download and then execute the external resource syncronously. To learn more about this process, MDN has a nice [`reference guide`](https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/Elements/script#async_and_defer).
+T> A couple other script loading strategies exist. Deferred loading is one such alternative to the above, where instead scripts are consolidated into the `<head>` and are given the `defer` attribute. This strategy downloads the external script resource(s) in parallel with document parsing, and will execute the scripts in order of document appearance after parsing has finished. This is in contrast to the above, in which the parser pauses to download and then execute the external resource synchronously. To learn more about this process, MDN has a nice [`reference guide`](https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/Elements/script#async_and_defer).
 
 In this setup, `index.js` explicitly requires `lodash` to be present, and binds it as `_` (no global scope pollution). By stating what dependencies a module needs, webpack can use this information to build a dependency graph. It then uses the graph to generate an optimized bundle where scripts will be executed in the correct order.
 

src/content/index.mdx

@@ -4,7 +4,7 @@ sort: -1
 ---
 
 import FirstLeft from '../components/Splash/first/left.mdx';
-import FirstRigth from '../components/Splash/first/right.mdx';
+import FirstRight from '../components/Splash/first/right.mdx';
 import SecondLeft from '../components/Splash/second/left.mdx';
 import SecondRight from '../components/Splash/second/right.mdx';
 
@@ -15,7 +15,7 @@ import SecondRight from '../components/Splash/second/right.mdx';
     <FirstLeft />
   </div>
   <div className="splash__right">
-    <FirstRigth />
+    <FirstRight />
   </div>
 </div>
 

src/content/plugins/normal-module-replacement-plugin.mdx

@@ -19,7 +19,9 @@ new webpack.NormalModuleReplacementPlugin(resourceRegExp, newResource);
 
 Note that the `resourceRegExp` is tested against the request you write in your code, not the resolved resource. For instance, `'./sum'` will be used to test instead of `'./sum.js'` when you have code `import sum from './sum'`.
 
-Also please note that when using Windows, you have to accommodate for the different folder separator symbol. E.g. `/src\/environments\/environment\.ts/` won't work on Windows, you have to use `/src[\\/]environments[\\/]environment\.ts/,` instead.
+
+Also please note that when using Windows, you have to accommodate the different folder separator symbol. E.g. `/src\/environments\/environment\.ts/` won't work on Windows, you have to use `/src[\\/]environments[\\/]environment\.ts/,` instead.
+
 
 ## Basic Example