This article is the fifth in a series on the source code of Taro. Below is a link to the series.
- Taro source code interpretation – @tarojs/ Taro article
- Taro source code interpretation – @Tarojs/CLI
- Taro source code interpretation – Taro Build
- Taro source code interpretation – Minirunner
- Taro source code interpretation – TarominiPlugin
In the previous Taro source interpretation, Minirunner, I explained the workflow for Minirunner in Taro-CLI, which is essentially a Webpack build process.
This article will complement the Minirunner article by 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, on the other hand, generally implements hook functions that are registered in the Webpack Compiler during different life cycles to process additional logic at specific times.
Let’s take a look at the apply method in the TarominiPlugin (as shown below)
Let’s analyze what the apply method of the TarominiPlugin does, as follows:
| code | Analysis of the |
|---|---|
The first148-156. 行 |
Get some parameters passed by the plug-in, and get the path to the entry file |
The first158 行 |
Register the lifecycle hook function that is executed when Webpack starts compiling |
The first174 行 |
Register the lifecycle hook function and execute it after a new compilation is triggered in Webpack listening mode |
The first197 行 |
Register the lifecycle hook function and execute it before Webpack finishes compiling |
The first211 行 |
Register the lifecycle hook function, which is executed after compilation is successful. Compilation represents a separate compilation |
The first281 行 |
Register the lifecycle hook function that is executed before Webpack generates the resource 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, the call continuesTaroNormalModulesPluginThe plug-inapplymethods |
Next we need to parse several of the lifecycle hook functions registered by Apply. Let’s start by looking at the value of AppEntry, our entry file (as shown below).
Lifecycle hook -run
We will now start parsing from one of the hooks registered with the TarominiPlugin, run. The code implementation is shown below
The TarominiPlugin calls an asynchronous hook using TapAsync. The name of the hook is the variable PLUGIN_NAME, which is the TarominiPlugin.
Then we look at line 161, where the run method in the tarominiPlugin instance is called, passing in the Compiler as an argument. After the run method completes, the TaroLoadChunksPlugin plug-in is called, which is the hook function registered in the run lifecycle.
Let’s take a look at the implementation of the first run method called in this hook function. (as shown below)
As you can see from the comments in the code above, all the run method does is analyze the app entry file, collect page and component information, and finally add a resource module to the dependencies attribute.
To obtain the AppConfig
Let’s go to the run method and take a look at the step of getting the app configuration. This step calls the getAppConfig method, which is essentially analyzing app.config.js, the small program configuration file that Taro officially provides. (as shown below)
In addition to collecting the basic configuration of the applet, Taro takes care of the global custom component registered with UsingComponents and collects it into the internal Components property for later use.
The resulting collected configuration is similar to the base configuration shown in the figure below, which is then stored in the AppConfig property in the TarominiPlugin instance. (as shown below)
Collect applet page, component information
Next, let’s look at the getPages method. (as shown below)
In the getPages method, we mainly do the following work:
| Lines of code | instructions |
|---|---|
The first364 行 |
Collect pages that need to be pre-rendered |
The first365 行 |
Collect the tabbar file, which is mainly used to collect the custom components in the tabbar |
The first366 行 |
Collect pages and store them inpagesProperties of the |
The first380 行 |
Collect the pages in the subcontract configuration |
The important thing to note in the getPages method is that the properties Pages finally collects are not only the path information, but also some other information, such as whether the page is a native page or component of the applet, the page name, the path to the page file… (as shown below)
After all the pages are collected, the pages are read and the dependencies are analyzed, that is, the getPagesConfig method. (as shown below)
In this step, you focus on analyzing the component relationships that the page depends on and storing them in the Components information. After that, the familiar Taro compiler start prompt screen will appear.
After analyzing the dependencies between page components, the project’s DarkMode configuration is obtained through the getDarkMode method and the topic information is stored in the ThemeLocation property of the TarominiPlugin instance.
Collect dependencies
After collecting the configuration files and component files of the applet page, it is time to go to the next step to collect some dependencies.
Let’s look at the getConfigFiles method first. (as shown below)
As you can see from the figure above, this method pulls all the configurations from FileConfigs and adds them to Dependencies. Then, a Webpack hook function is registered to remove all the config-related chunks before creating the chunk assets.
After the dependency collection is complete, Dependencies is a Map instance that records information about the config configuration file. (as shown below)
After collecting the config file, the information of resource modules such as APP, template component, page and component is recorded in Dependencies through AddEntries. (as shown below)
At this point, the run method process is completed and some basic pages, components and dependencies in the project are collected. Also, this information is recorded in the TarominiPlugin instance, and the resource module related information is recorded in the dependencies property.
In the TarominiPlugin, following the single-responsibility design principle, the run method basically only does the work of collecting project information, and does not do any side effects. Following the single responsibility design principle can make the work flow of TarominiPlugin more clear, and also make our source code reading easier (*￣, ￣).
TaroLoadChunksPlugin
When the hook is run, in addition to running the run method to collect basic information about the project, another plug-in, Taroloadchunksplugin, is called.
The main purpose of this plug-in is to handle the public files that need to be extracted from the project. For details, see Taro-CommonChunks, Webpack-RuntimeChunk, Webpack-SpiltChunks.
summary
That’s what the first hook registered in the TarominiPlugin, run, does. This hook function will be executed at compile time. It collects the basic pages, components, and dependencies of the project and record them in the TarominiPlugin. For use in later compilation steps.
In the following articles, we will analyze the other Webpack hooks registered in the tarominiPlugin in detail, and interpret the source code of the tarominiPlugin clearly.
One last thing
If you’ve already seen this, I hope you’ll like it before you go
Your thumb up is the greatest encouragement to the author, and can also let more people see this article!
If you found this article helpful, please help to light up Star on GitHub.
