Static Compilation for Multi‑Scene SaaS Car Services Using Webpack Resolve Plugins

Background : When promoting a SaaS‑based car‑service platform that must support both a main brand and multiple small brands, the differences in user interaction, API data, and business processes cause heavy code branching. This leads to poor readability, large runtime bundles, and difficulty isolating features across scenarios.

What is static compilation? In this context, static compilation means moving as much business logic as possible to the compile‑time phase, packaging the necessary code into the build artifact to reduce runtime overhead. It is achieved by splitting divergent business logic into separate files distinguished by filename suffixes and using a Webpack resolve plugin to handle the branching.

Goals and Benefits :

Isolate differentiated scenarios while sharing core car‑service capabilities.

Split multi‑scenario business logic to lower testing and regression effort.

Reduce the impact and risk of changes on other platforms during development and maintenance.

Achieve differentiated packaging to shrink bundle size and improve cold‑start speed.

Improve code cleanliness and independence.

Enable technical possibilities for business capability orchestration.

Usage Scenarios include business isolation (marketing, global notification bar, temporary lock, helmet capability, ringing‑find‑car, etc.), style isolation (unlock page footer cards, riding‑in‑progress cards, lottie animations, pop‑up dialogs), and core capability isolation (Bluetooth, QR‑code scanning, WebView hosting).

How to achieve static compilation : First resolve the business logic branching problem, then develop a custom resolve plugin that extracts and compiles code based on file‑name suffixes.

Before the solution : Runtime bundles contain both main‑brand and small‑brand hooks, resulting in large bundle sizes and tangled code.

After the solution : Files are imported without specifying exact filenames; the resolve plugin selects the appropriate suffix (e.g., *.mini.ts for small brands, *.oho.ts for the main brand), producing much smaller, scenario‑specific bundles.

Directory structure changes :

Old: Separate files like /mini.ts (small brand) and /oho.ts (main brand).

New: Use suffixes – *.mini.ts (including *.mini.alipay.ts , *.mini.weapp.ts ) and *.oho.ts (including *.oho.alipay.ts , *.oho.weapp.ts ).

Limitations of basic require :

Works only in Node environments.

Resolves only .js , .json , .node files.

Requires full file paths; cannot resolve directories.

Returns only a path without rich metadata.

Creating a plugin : The plugin receives source and target parameters. It taps into Resolver.hooks['source'] to register a handler, and after processing calls doResolve to trigger the target hook, allowing plugins to be chained like building blocks.

Tapable overview : Tapable, maintained by the Webpack team, provides an event‑emitter‑like system for custom hooks. It supports synchronous ( tap ) and asynchronous ( tapAsync ) hooks, enabling plugins to interact at various compilation stages.

enhanced‑resolve : A core Webpack package that extends module resolution capabilities, adding search paths and custom rules to improve performance and maintainability.

Pipeline : Various hooks are linked via Resolver.doResolve . Each hook may have multiple plugins, forming a chain that processes file resolution step by step.

Plugin flow :

Instantiate a resolver via ResolverFactory.createResolver .

Register numerous hooks on the resolver instance.

Invoke myResolver.resolve to start the main file‑resolution flow.

Internally, doResolve triggers the first hook (e.g., resolve ), which finds a registered plugin such as ParsePlugin .

ParsePlugin performs initial parsing and then calls doResolve for the next hook ( parsed-resolve ), continuing the chain.

Integration steps :

Install the custom package: npm install @hb/multi-scene-resolve-plugin .

Import the package in the project’s configuration file.

Replace Taro’s built‑in multiPlatformPlugin with the custom plugin.

Usage tips :

All platform‑specific files must expose a unified interface.

Import files by their base name without suffixes.

Provide a platform‑agnostic default file to avoid TypeScript errors.

Q&A :

Why replace Taro’s MultiPlatformPlugin ? Because it cannot resolve paths like /pages/riding/useHelmet.oho.weapp.ts , and parallel processing would increase compile time.

Are the registration hooks limited to described-resolve and resolve ? No; other hooks such as before-file or file can be used before the filename suffix is bound.

Why can’t the custom plugin run before the built‑in one? The built‑in plugin has higher priority in Taro’s runner chain, and changing the order would affect its file‑filtering logic.

Why write a Webpack plugin instead of a Taro plugin? Webpack plugins are more universally applicable, and Taro’s plugin system only became stable from version 3.6.3.