This article is the fifth in Taro’s series of source code interpretations. links to the series are listed below.
- Source code interpretation – @tarojs/ Taro
- Taro source code interpretation – @tarojs/ CLI
- Taro source code interpretation – Taro build
- Taro source code interpretation – miniRunner
- Taro source code interpretation – TaroMiniPlugin last article
Taro: miniRunner: miniRunner: miniRunner: miniRunner: miniRunner: miniRunner: miniRunner: miniRunner: miniRunner: miniRunner
This article will complement the miniRunner article, focusing on the TaroMiniPlugin in miniRunner.
Without further ado, let’s begin.
TaroMiniPlugin overview
The TaroMiniPlugin is a WebPack plugin that, according to the WebPack plug-in feature, calls the Apply method on the plug-in instance when the plug-in is installed. The Apply method generally registers the corresponding hook functions in the different life cycles of the Webpack Compiler to handle additional logic at specific times.
Let’s start by looking at the Apply method in TaroMiniPlugin (see figure below)
Let’s analyze what the Apply method of the TaroMiniPlugin does as follows:
| code | Analysis of the |
|---|---|
The first148-156. 行 |
Gets some parameters passed in by the plug-in, and gets the path to the entry file |
The first158 行 |
Register life cycle hook functions to be executed when WebPack starts compiling |
The first174 行 |
Register the lifecycle hook function to execute after a new compilation is triggered in WebPack listening mode |
The first197 行 |
Register lifecycle hook functions to execute before WebPack finishes compiling |
The first211 行 |
Register the lifecycle hook functions to be executed after the compilation, which represents a single compilation |
The first281 行 |
Register lifecycle hook functions to be executed before WebPack generates resources to the Output directory |
The first288 行 |
Register the lifecycle hook function, which is executed after WebPack generates the resource to the Output directory |
The first295 行 |
After registering the lifecycle hook function, continue the callTaroNormalModulesPluginThe plug-inapplymethods |
Next we need to parse several lifecycle hook functions registered by Apply. Let’s start by looking at the value of the appEntry, which is our entry file (shown below).
Lifecycle hook-run
We will now start parsing from a hook run registered with the TaroMiniPlugin. The code implementation is shown below
The TaroMiniPlugin uses tapAsync to call an asynchronous hook named PLUGIN_NAME (TaroMiniPlugin).
We then look at line 161, where the run method in the TaroMiniPlugin instance is called and compiler is passed in as a parameter. After the run method completes, the TaroLoadChunksPlugin plug-in is called, which is the hook function registered with the run lifecycle.
Let’s take a look at the implementation of the run method originally called in this hook function. (As shown below)
As you can see from the comments in the code above, the run method analyzes the app entry file, collects page and component information, and adds the resource module to the Dependencies property.
To obtain the AppConfig
Going into the run method, let’s first look at the step of getting the app configuration. This step calls the getAppConfig method to analyze app.config.js, which is the applet configuration file provided by Taro. (As shown below)
Taro collects the basic configuration of the applet. In addition, Taro handles global custom components registered with usingComponents and collects them into internal components properties for later use.
The resulting collected configuration is similar to the base configuration shown in the following figure, which is then stored in the appConfig property in the TaroMiniPlugin instance. (As shown below)
Collect information about applets and components
Next, let’s look at the getPages method. (As shown below)
In the getPages method, we do the following:
| Lines of code | instructions |
|---|---|
The first364 行 |
Collect pages that need to be pre-rendered |
The first365 行 |
Collecting tabbar files deals with collecting custom components in tabbar |
The first366 行 |
Collection page, stored inpagesProperties of the |
The first380 行 |
Collect the pages in the subcontracting configuration |
The getPages method collects not only path information, but also other information, such as whether it is a native page or component of the applet, page name, page file path… (As shown below)
After all the pages are collected, the pages are read and the dependencies are analyzed, which is the getPagesConfig method. (As shown below)
In this step, you analyze the component relationships that the page depends on and store them in the Components information. Then, the familiar Taro compilation start prompt screen will appear.
After analyzing the dependencies between page components, the darkMode configuration of the project is retrieved using the getDarkMode method, storing the subject information in the themeLocation property of the TaroMiniPlugin instance.
Collecting dependencies
After collecting the applets page configuration files and component files, move on to the next step of collecting some dependencies.
Let’s start with the getConfigFiles method. (As shown below)
As you can see from the figure above, this method takes all the configuration from fileConfigs and adds it to Dependencies. Then, a Webpack hook function is registered to remove all of the config related chunks before chunk assets are created.
After the dependency collection is complete, Dependencies are a Map instance that records information about the Config configuration file. (As shown below)
After the config file is collected, addEntries are added to the dependencies of app, template components, pages, components and other resource modules. (As shown below)
At this point, the run method process completes, collecting the basic pages, components, and dependencies of the project. Also, record this information in the TaroMiniPlugin instance, and then record information about the resource module in the Dependencies property.
In the TaroMiniPlugin, the single responsibility design principle is followed, and the RUN method basically does the collection of project information without any side effects. Following the principle of single responsibility design can make the workflow of TaroMiniPlugin clearer and also make our source code reading easier (*￣).
TaroLoadChunksPlugin
In addition to running the run method to collect basic information about the project, another plug-in, TaroLoadChunksPlugin, is called when the Run hook is executed.
The main purpose of this plug-in is to process the public files that need to be extracted from the project. For details, see taro-commonchunks, WebPack-Runtimechunk, and Webpack-spiltchunks.
summary
This is what the first hook run registered in TaroMiniPlugin does. This hook function will be executed at compile time. The main thing to do is to collect the basic pages, components, and dependencies in the TaroMiniPlugin. For use in later compilation steps.
In future articles, we will continue to analyze the other Webpack hooks registered in TaroMiniPlugin in detail, as well as the source code of TaroMiniPlugin.
One last thing
If you’ve already seen it, please give it a thumbs up
Your likes are the greatest encouragement to the author, and can also let more people see this article!
If you find this article helpful, please help to light up the star on Github.