Skip to content

Commit

Permalink
Merge pull request #16988 from ersachin3112/fix-grammer
Browse files Browse the repository at this point in the history
docs: update grammar  mistakes in examples
  • Loading branch information
TheLarkInn committed Apr 14, 2023
2 parents f1ef2ed + eb817d5 commit c349542
Show file tree
Hide file tree
Showing 4 changed files with 9 additions and 9 deletions.
8 changes: 4 additions & 4 deletions examples/scope-hoisting/README.md
Expand Up @@ -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)

Expand Down
6 changes: 3 additions & 3 deletions examples/scope-hoisting/template.md
Expand Up @@ -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)

Expand Down
2 changes: 1 addition & 1 deletion 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.

Expand Down
2 changes: 1 addition & 1 deletion 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.

Expand Down

0 comments on commit c349542

Please sign in to comment.