Extending a compiled platform requires writing a [Taro plugin](. /plugin) for compile-time and run-time compatibility respectively.
@tarojs/plugin-platform-weapp as an example.
Handles compile-related operations such as Webpack configuration, template generation rules, etc.
Pre-reading: [How to Write a Taro Plugin]。
First we need to write a Taro plugin to register our compilation platform, eg.
Register a compilation platform
The platform name for the CLI compile command.
If 'xxx' is configured, the CLI command to use when compiling this platform:
Incorporate the specified fields from the Taro compilation configuration into the compilation.
Taro minn program related configuration is placed under the
mini field by default, so in general it is sufficient to configure
The entry function for platform compilation accepts an argument
arg, in which we can start writing the logic for end-platform compilation.
Next add to the plugin entry function mentioned in the previous section.
We abstracted the logic commonly used at compile time into a base class TaroPlatformBase, which developers can [inherit](./platform-plugin-base#custom platform class) from this base class to enable platform compilation.
The compilation interface of the above custom platform class is then called in the plugin entry function as follows.
Handles runtime-related operations such as APIs, components, Taro runtime logic, etc.
runtime.ts is our runtime entry file, which
Webpack will inject into
app.js for reference when it is compiled.
- Use the
mergeReconcilerfunction to merge the custom
hostConfiginto the global Reconciler.
- Use the
mergeInternalComponentsfunction to merge custom component information components.ts into the global
internalComponentscomponent information object.
The runtime-utils.ts is extracted to make it easier for other plugins to reference
In order for
Webpack to know where to refer to the above runtime entry files,
runtimePath needs to be configured.
In Taro, users need to refer to Taro's built-in API and the Promise-ified mini program API from
@tarojs/taro package only provides the built-in API, we need to add the API for the mini program and the API we want to mount on the Taro object by configuring
Reconciler with initNativeApi option to add APIs for mini program to the global Taro object and the APIs we want to mount on the Taro object.
|global||object||Mini Program global objects, such as WeChat wx|
|noPromiseApis||Set||New Synchronization API|
|needPromiseApis||Set||New Asynchronous API|
processApis function helps us do three things.
- mount all of the platform's common mini program APIs onto a Taro object
- mount the common mini program global object properties on the Taro object
- mount the user-input mini program API on the Taro object
The plugin is packaged using
Rollup and requires the following files to be packaged out.
|src/index.ts||cjs||YES||Plugin entry for Taro CLI parsing|
|src/runtime-utils.ts||es||NO||Collection of runtime tools for reference by inherited subclasses|
|src/components-react.ts||es||NO||Need to be implemented when there are new components for React to reference|
Note that Taro-related packages need to be configured with
external to avoid repackaging.
The types maintained by the Taro core library may not include components and APIs added by the current plugin, in which case we need to perform [module augmentation (module augmentation)] for
Create a type definition file:
The developer can simply introduce this file in the type definition file.