在构建产物上，我们则结合了几个工具链产物的特点，首先构建 babel 转译过的 es5 文件和对应的声明文件，用于普通项目中。其次构建保留的 import/export 的 esmodule，用于对包体积有要求的项目做 treeShaking。然后，将对应的 md 构建成可直接阅读器预览的 demo 放在 build 文件夹中与 Fusion 组件对齐，再将 lib 文件夹下的文件复制到 build 目录中，方便乐高构建和辨认（乐高构建的时分会直接去找 build 目录下的 view.js 和 view.mobile.js 等文件）。

工具链的选择

在工具链的选择上，我们最终选择了乐高的开发套件 vdev 作为底座停止扩展，这样做的思索是可视化组件的整套开发体系较重，且未插件化，抽取迁移的成本较高。其次，相比其他两套工具链，vdev 在大团队的基础架构部门维护，沟通协作相对复杂。剩余的部分我们并没有完全重造，而是尽能够地复用起现有的 build-scripts 体系下的插件。我们首先对 vdev 停止了改造，支持了 build-scripts 相关体系的调用，剩余的开发则基于 build-scripts 下的 plugin 末尾开发，最终的大致链路如下：

pc.json 大致如下：

在开发的时分我们定下了一个准绳，基于通用规则下的 PC、Mobile 和小顺序预览，我们尽量经过官方的 build-plugin-component 来完成，不支持的功用或 bug 经过共建补齐或修复，而针对融合包的特殊规则，如融合需求的特殊配置处置，构建后的文件转移等逻辑，经过 build-scripts 体系下后序插件（我们这里命名为 build-plugin-vdev-component）可以对前序插件定义的配置做进一步处置的特性来添加。这样既减小了后续的维护成本，又可以经过 build-plugin-component 协助到更多的业务。

确定好基础的架构之后，我进一步定义了融合包相关的 npm scripts：

start：用于启动可视化部分的调试，包含设计器和预览

startPC：用于启动 PC 部分的调试

startMobile：用于启动移动端 Web 部分的调试

startMiniapp：用于启动移动端小顺序部分的调试

build：用于生成上文提到的构建产物

其中除 start 外，其他都依托 build-scirpts 插件体系来完成。

调试主要处置的成绩

大致框架都确定后，就要末尾详细的开发流程。start 相关的流程需求修正的不多，主要是把组件名 alias 到对应的入口（PC 到 view.tsx, Mobile 到 view.mobile.tsx），剩下的主要是补全 build-plugin-component 中缺失的功用，比如 Rax 部分里对 scss 的支持，inlineStyle 配置的支持。有个值得稍微提一下的点是关于对 demo 文件中 jsx 的处置。我们都知道 jsx 是 React 提出的 js 的增强型语法，用于将模板可以完全运用 js 语法来描画，实践在阅读器是不能直接辨认的，普通的处置方式是经过 babel 转换成对应的转换语法，如把

转换成：

关于的 jsx 标签如 <div> 会被转换成 React.createElement("div") 。这在单一框架下是没有成绩的，但由于融合包中 demo 是在 PC 和 移动端复用的，那这里是转换成 React.createElement 还是 Rax.createElement 呢？显然都不太适宜，他只要在详细启动调试 PC 还是小顺序时才能决议，而且 Rax 官方其实更引荐的写法是不要直接援用全量的 Rax 变量，而是从 Rax 变量中按需加载对应的 api，如 createElement，写法上自然有区别。所以我们在 demo 文件的写法上取了一个交集，大致如下：

demo 文件的写法上是基于 PC 的视角的，援用的依赖是 react 的 Component 和 createElement，以及基础组件库 @ali/deep。在启动小顺序调试时，react alias 到 rax ，@ali/deep alias 到 @ali/deep-mobile。而 jsx 相关的，如 <div> 会被转换成 createElement("div") ，这样从写法上保证了编译后的可行性。

构建主要处置的成绩

在 build 的进程中，由于要同时构建出 PC 和 Mobile 的 demo，而 build-plugin-component 只能启动 Rax 或许 React 其中一边的构建，显然这无法满足我们的需求，假设调用两次脚本，中间又存在着少量的重复操作，如文件夹的新增和删除等等。 我们选择的是运用 build-plugin-component 的 rax 部分，并在后序插件 build-plugin-vdev-component 里另起一个 React 的 webpa ck task，同时完成 PC 和 Mobile 的 demo 构建。

在构建 es5 的文件时，也遇到了 jsx 的编译成绩，由于源码中包含了一部分 react 文件也包含了一部分 rax 文件，在 start 时还可以按照 entry 的依赖链来设置 babel 配置，但是 build 时对源文件只过 babel 没有 webpack，所以要运用其他的办法来处置。 我们采取的方式 是先剖析每 个文件的 AST，从文件的包援用上剖析出该文件是一个 React 还是 Rax 组件，然后采用不同的 babel 配置来停止编译。 这里为什么没有采用和上文提到的 demo 里的异样的方式停止处置呢？ 缘由是 demo 的方式对 createElement 的引入是强依赖，写法上比较受限，在源码部分我们希望可以让用户拥有更灵敏的运用方式。

(责任编辑：admin)