docs: update grammar mistakes in examples

examples/scope-hoisting/README.md

@@ -4,17 +4,17 @@ This is the dependency graph for the example: (solid lines express sync imports,
 
 ![](graph.png)
 
-All modules except `cjs` are EcmaScript modules. `cjs` is a CommonJs module.
+All modules except `cjs` are EcmaScript modules. `cjs` is a CommonJS module.
 
-The interesting thing here is that putting all modules in single scope won't work, because of multiple reasons:
+The interesting thing here is that putting all modules in a single scope won't work, because of multiple reasons:
 
 - Modules `lazy`, `c`, `d` and `cjs` need to be in a separate chunk
 - Module `shared` is accessed by two chunks (different scopes)
-- Module `cjs` is a CommonJs module
+- Module `cjs` is a CommonJS module
 
 ![](graph2.png)
 
-webpack therefore uses a approach called **"Partial Scope Hoisting"** or "Module concatenation", which chooses the largest possible subsets of ES modules which can be scope hoisted and combines them with the default webpack primitives.
+Webpack, therefore, uses an approach called **"Partial Scope Hoisting"** or "Module concatenation", which chooses the largest possible subsets of ES modules which can be scope hoisted and combines them with the default webpack primitives.
 
 ![](graph3.png)
 

examples/scope-hoisting/template.md

@@ -4,17 +4,17 @@ This is the dependency graph for the example: (solid lines express sync imports,
 
 ![](graph.png)
 
-All modules except `cjs` are EcmaScript modules. `cjs` is a CommonJs module.
+All modules except `cjs` are EcmaScript modules. `cjs` is a CommonJS module.
 
-The interesting thing here is that putting all modules in single scope won't work, because of multiple reasons:
+The interesting thing here is that putting all modules in a single scope won't work, because of multiple reasons:
 
 - Modules `lazy`, `c`, `d` and `cjs` need to be in a separate chunk
 - Module `shared` is accessed by two chunks (different scopes)
 - Module `cjs` is a CommonJs module
 
 ![](graph2.png)
 
-webpack therefore uses a approach called **"Partial Scope Hoisting"** or "Module concatenation", which chooses the largest possible subsets of ES modules which can be scope hoisted and combines them with the default webpack primitives.
+Webpack, therefore, uses a approach called **"Partial Scope Hoisting"** or "Module concatenation", which chooses the largest possible subsets of ES modules which can be scope hoisted and combines them with the default webpack primitives.
 
 ![](graph3.png)
 

examples/side-effects/README.md

@@ -1,4 +1,4 @@
-This example shows how the `sideEffects` flag for library authors works.
+This example shows how the `sideEffects` flag works for library authors.
 
 The example contains a large library, `big-module`. `big-module` contains multiple child modules: `a`, `b` and `c`. The exports from the child modules are re-exported in the entry module (`index.js`) of the library. A consumer uses **some** of the exports, importing them from the library via `import { a, b } from "big-module"`. According to the EcmaScript spec, all child modules _must_ be evaluated because they could contain side effects.
 

examples/side-effects/template.md

@@ -1,4 +1,4 @@
-This example shows how the `sideEffects` flag for library authors works.
+This example shows how the `sideEffects` flag works for library authors.
 
 The example contains a large library, `big-module`. `big-module` contains multiple child modules: `a`, `b` and `c`. The exports from the child modules are re-exported in the entry module (`index.js`) of the library. A consumer uses **some** of the exports, importing them from the library via `import { a, b } from "big-module"`. According to the EcmaScript spec, all child modules _must_ be evaluated because they could contain side effects.