Previous article (juejin.cn/post/700202…) The core execution process of Webpack is analyzed from the packaging results. This article explains in detail the laoder trigger timing and execution process to solve all the problems of Loader at one time.

1. Why do I need to configure loader

Because Webpack only knows JS and JSON, non-JS and JSON file types need to be converted by Loader into standard JS modules before they can be packaged and processed by Webpack.

2. What is the essence of loader

A loader is essentially a JavaScript module exported as a function. For example, the simplest loader:

Module. exports = function(content, map, meta) {return 'export default "Convert by my custom loader: ${content}"'; / / note: When multiple parameters need to be returned, Async (null, result, map, meta) // Async (null, result, map, meta) // Async (null, result, meta) // Callback (null, result, callback) Map, meta) // Only one argument can return}Copy the code

Webpack will inject three parameters into the loader:

Content: indicates the content of the resource file. / / must

Map: source map generated by the loader // Optional

Meta: Other information that needs to be shared by the rear loader. This parameter is optional

Understanding this essence, it is very simple to develop a loader yourself. For example, create a loaders directory and create a my-loader.js file that contains exported javascript modules.

The default module resolution is from the current node_modules lookup, how to find their own loader? You only need to configure the lower resolution rules

Node_modules resolveLoader: {modules: [path.resolve(__dirname, 'loaders'), 'node_modules'] }Copy the code

3. When is loader triggered

Previous article (juejin.cn/post/700202…) We have learned the overall packaging process of Webpack, where loader trigger time is marked in red:

Real trigger is to call the module build, build corresponding source file webpack/lib/NormalModule js method of build, the build method call doBuild, performed runLoaders doBuild method, the diagram below:

RunLoaders is a separate tool library (loader-runner) that performs resource loading and conversion. How to do this continues to question 4.

4. How is loader implemented

Before learning about the loader execution process, you need to know that the Loader function includes pitch and normal. Pitch is not mandatory. If there is a pitch, it will be executed first.

Through the execution process, we also know why loader executes from right to left. In fact, loader executes a recursive call. Resources are processed only when it determines that the current is the last loader.

IteratePitchingLoaders function

ProcessResource Function execution process

IterateNormalLoaders:

5. What is the execution sequence of loader

In webPack configuration files, we often see two scenarios:

Scenario 1: How to Configure multiple Loaders for the same rule?

The execution priority is Pre Loader > Inline Loader > Normal Loader > Post Loader. You can use Enforce to change the execution sequence of the Loader. If no enforce is configured, the priorities are the same.

Scenario 2: Configuring the execution sequence of Multiple Loaders for a rule?

In the configuration, the same priority is executed from right to left and from bottom to top. I believe I have understood why this order is executed by question 4Loader.

Summary: The actual execution order of Loader depends on the type of Loader, pitch method, and inline-loader prefix.

Through the above 5 questions, I believe that all the questions about Loader have been basically solved, and it is not easy to code calligraphy and painting. Thank you for your support