docs: clarify webpack loader execution order (right-to-left)#8136
docs: clarify webpack loader execution order (right-to-left)#8136alexander-akait merged 5 commits intowebpack:mainfrom
Conversation
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
| Module loaders can be chained. Each loader in the chain applies transformations to the processed resource. A chain is executed in reverse order. The first loader passes its result (resource with applied transformations) to the next one, and so forth. Finally, webpack expects JavaScript to be returned by the last loader in the chain. | ||
|
|
||
| The above order of loaders should be maintained: [`'style-loader'`](/loaders/style-loader) comes first and followed by [`'css-loader'`](/loaders/css-loader). If this convention is not followed, webpack is likely to throw errors. | ||
| The above order of loaders should be maintained: [`'style-loader'`](/loaders/style-loader) should be listed before [`'css-loader'`](/loaders/css-loader) in the `use` array, but webpack applies them from right to left—so `'css-loader'` runs first, then `'style-loader'`. If this convention is not followed, webpack is likely to throw errors. |
There was a problem hiding this comment.
To be honestly and before and now is misleading, I think we should rewrite it...
|
Rewrote this part to make the execution order clear and removed the confusing wording. Let me know if this works 👍 |
|
Hi @alexander-akait, just checking if the latest rewrite looks good to you. |
|
|
||
| T> webpack uses a regular expression to determine which files it should look for and serve to a specific loader. In this case, any file that ends with `.css` will be served to the `style-loader` and the `css-loader`. | ||
| ```js | ||
| use: ["style-loader", "css-loader"]; |
There was a problem hiding this comment.
Let's use other loaders than style-loader and css-loader, they will be deprecated soon in favor of experiments.css, you can use postcss-loader and sass-loader/less-loader for this example
5723f45 to
d128213
Compare
There was a problem hiding this comment.
Pull request overview
Updates the Asset Management guide to correct the explanation of webpack loader execution order, clarifying that loaders run from right to left in a use array.
Changes:
- Adds a new contributor entry.
- Rewrites the loader-chaining explanation to emphasize right-to-left execution order and adds an illustrative example.
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
| ```js | ||
| use: ["postcss-loader", "sass-loader"]; | ||
| ``` | ||
|
|
||
| Here, `css-loader` runs first and processes the CSS, followed by `style-loader`, which injects the result into the DOM. | ||
|
|
||
| This enables you to `import './style.css'` into the file that depends on that styling. Now, when that module is run, a `<style>` tag with the stringified css will be inserted into the `<head>` of your html file. | ||
| So even though `style-loader` appears before `css-loader` in the array, the execution happens in reverse order. |
There was a problem hiding this comment.
The example use: ["postcss-loader", "sass-loader"] doesn’t match the explanation below it: the text talks about css-loader/style-loader and DOM injection, but those loaders are not in the example array. This makes the execution-order clarification incorrect/confusing (with the current example, sass-loader would run before postcss-loader). Consider either switching the example to the ['style-loader', 'css-loader'] chain shown above, or updating the explanation to describe sass-loader -> postcss-loader correctly.
…s-loader and sass-loader
There was a problem hiding this comment.
Pull request overview
Copilot reviewed 1 out of 1 changed files in this pull request and generated 2 comments.
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
|
|
||
| T> webpack uses a regular expression to determine which files it should look for and serve to a specific loader. In this case, any file that ends with `.css` will be served to the `style-loader` and the `css-loader`. | ||
| ```js | ||
| use: ["postcss-loader", "sass-loader"]; |
There was a problem hiding this comment.
The new use snippet is not valid in a typical webpack.config.js object literal (; and double-quotes), and it’s inconsistent with the surrounding examples that use single quotes and a trailing comma. Consider changing it to a config-style property (single quotes, trailing comma) so readers can copy/paste it directly.
| use: ["postcss-loader", "sass-loader"]; | |
| use: ['postcss-loader', 'sass-loader'], |
| @@ -95,15 +96,19 @@ npm install --save-dev style-loader css-loader | |||
| }; | |||
| ``` | |||
|
|
|||
There was a problem hiding this comment.
This section shows test: /\.css$/i in the config diff, but the explanatory sentence about test being a regex that selects which files the rule applies to was removed. Consider reintroducing a short explanation (e.g., that this rule targets .css files) so the example is self-contained for readers unfamiliar with webpack’s module.rules format.
| In this rule, `test: /\.css$/i` is a regular expression that tells webpack to apply the rule to `.css` files. |
There was a problem hiding this comment.
Pull request overview
Copilot reviewed 1 out of 1 changed files in this pull request and generated 2 comments.
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
| ```js | ||
| use: ['postcss-loader', 'sass-loader'], | ||
| ``` | ||
|
|
||
| In this rule, `test: /\.css$/i` is a regular expression that tells webpack to apply the rule to `.css` files. | ||
|
|
||
| Here, `sass-loader` runs first and compiles Sass into CSS, followed by `postcss-loader`, which applies further transformations. | ||
|
|
There was a problem hiding this comment.
The example references test: /\.css$/i and describes how the rule applies to .css files, but the shown use: ['postcss-loader', 'sass-loader'] chain typically corresponds to .scss/.sass input (and the snippet omits the test line entirely). Consider either showing the full rule (including test) with a matching extension for sass-loader, or switching the example loaders to ones that apply to .css so the explanation stays internally consistent.
| Loaders in webpack are executed from **right to left** (i.e., from last to first in the `use` array). | ||
|
|
There was a problem hiding this comment.
This section explains the general right-to-left execution order, but it no longer explicitly ties that back to the earlier use: ['style-loader', 'css-loader'] example (i.e., that css-loader runs first and style-loader runs last). Adding one short sentence that applies the rule to the preceding config would better resolve the original confusion this PR is addressing.
|
Addressed all suggestions. Please review 🙌 |
Summary
Fixes a misleading explanation in
asset-management.mdxregarding loader execution order. Clarifies that webpack applies loaders from right to left, socss-loaderruns beforestyle-loader.What kind of change does this PR introduce?
docs
Did you add tests for your changes?
No (documentation change only)
Does this PR introduce a breaking change?
No
Use of AI
No