Taro 4.0 Beta 发布：支持开发鸿蒙应用、小程序编译模式、Vite 编译等

过去一年 Taro 团队的开发重心在 v3.7 版本上，在某个时间点，我们意识到 v3.7 已积聚了足够庞大的特性更新，或许这是一个发布 Major 版本的时机。再结合上 Taro 3 发布至今的三年多时间里，前端界已经历了种种变化，我们希望借助 Taro 4 实现更新 NodeJS 的最低支持版本，升级各种依赖库的版本等各种不兼容性更新，为 Taro 下一个三年的长远服役打下坚实的基础。

新年伊始，Taro 4 的首个 Beta 版本已正式发布。下文将详细介绍其包含的主要特性及体验方式，欢迎各位开发者参与体验尝鲜。

鸿蒙端平台支持 —— Web To Harmony

鸿蒙是我国自主研发的操作系统，拥有出色的性能和安全保障。越来越多互联网企业开始布局鸿蒙应用和生态，为开发者带来了新的机遇。但直接使用鸿蒙原生框架开发应用，存在一定门槛。开发者需要学习全新的 ArkUI 框架，并掌握 ArkTS 这门语言。这对大部分只接触过 Web 开发的前端工程师而言，是不小的挑战。

因此在 Taro 4 中，我们添加了对鸿蒙端平台的支持，和适配小程序方案类似的，通过偏运行时的适配方案，让开发者继续使用 React、Vue 等熟悉的框架语法，平稳过渡到鸿蒙应用开发。

开发者只需要在 Taro 4 的项目中安装一个简单的端平台插件，并在配置文件中对插件进行配置：

// config.ts
export default defineConfig(async (merge, { command, mode }) => {
  const baseConfig: UserConfigExport = {
    projectName: 'harmony-taro',
    // 使用鸿蒙端平台插件
    plugins: ['@tarojs/plugin-platform-harmony-ets'],
    // 配置鸿蒙编译工具和包名等信息
    harmony: {
		  compiler: 'vite',
		  hapName: 'entry',
		  name: 'default',
		  projectPath: "鸿蒙项目路径",
    },
		//...
  }
})

然后执行对应的打包命令就可以将 Taro 项目打包成鸿蒙 APP 应用了，具体步骤请参见 ：

$ taro build --type harmony --watch

另外，Taro 4 也支持开发者使用 CSS、SASS 和 SCSS 等格式的样式来进行鸿蒙应用的开发，Taro 4 会在编译时将这些样式转译成对应的鸿蒙样式，这样，开发者就可以完全使用 Web 开发的思维和语法，来开发高质量的鸿蒙应用。

在性能方面，Taro 4 在编译成鸿蒙端的时候，也支持下文提到的新的性能优化特性 CompileMode，对编译产出的鸿蒙应用进行深度性能优化，使其速度与流畅度媲美鸿蒙原生应用。

总的来说，对于熟悉 Web 开发的前端开发者来说，相比直接使用 ArkTS，Taro 的开发体验更为顺畅，学习成本也更低。开发者可以充分复用现有的 React 项目，以最快速度完成多端适配，在未来我们也会增加对 Vue 的鸿蒙化支持。

小程序性能优化 —— CompileMode

Taro 3 是重运行时框架，当节点数量增多到一定量级时，渲染性能会大幅下降，出现白屏时间长、交互延时等问题。

在分析微信小程序的模板解析算法后，我们发现 Taro 3 基于 <template> 的渲染方式是瓶颈所在，这种渲染方式会比小程序原生写法多 3~4 倍的渲染层虚拟 DOM 节点。在长列表等页面节点数较多的场景中，性能差距会被急速放大，卡顿随之而来。

因此，Taro React 将推出小程序编译模式（CompileMode），让开发者可以手动对存在性能问题的组件进行优化。以京东某小程序的首页商品长列表场景为例，使用 CompileMode 优化后能提升约 30% 以上的首开渲染性能。功能的详细设计请查阅 。

使用方法：

// 只需要给小程序基础组件添加 compileMode 属性，该组件及其 children 将会被编译为单独的小程序模板
function GoodsItem () {
  return (
    <View compileMode>
      ...
    </View>
  )
}

自 Taro v3.6.22 开始也加入了对 CompileMode 的支持。开发者在 Taro 编译配置中设置 mini.experimental.compileMode = true 后即可使用。

React Native 适配升级 —— 支持 0.73 版本

，Taro 将与 RN 社区保持同步，将默认的 RN 版本更新到 0.73。

React Native 0.73 的更新重点包括对 Hermes 调试的改进、稳定的符号链接支持、Android 14 支持以及新的实验性特性。其中，调试方面的改进包括 Hermes 现在可以在后台捕获所有 console.log() 调用，并在首次连接调试器时发送到控制台，提供了一个新的 JavaScript 调试器体验。此外，React Native 模板在 Android 上改为使用 Kotlin 代替 Java，并且 React Native 已完全支持 Android 14。新架构更新继续推进，包括发布新的 Bridgeless 模式。此版本还弃用了一些旧的调试特性和对 @types/react-native 的支持。欲了解更多详细信息，请访问 。

React Native 0.73 版本中增加的稳定符号链接支持对使用 pnpm 的项目非常有利。这是因为 pnpm 依赖于符号链接来管理 node_modules，而以前 React Native 对这种结构的支持不够完善。Taro 4 改进了 React Native 模板 对 pnpm 的支持，使得在 React Native 项目中使用 pnpm 变得更加方便和高效。这样的改进为开发者提供了更多的包管理选择，特别是在面对大型和复杂项目时，能够更好地管理依赖和提高构建效率。

新的编译系统支持 —— Vite

Vite 相信大家都已经很熟悉，这里就不做过多的介绍了。由于其使用浏览器原生的 ES 模块加载机制来直接提供模块，除了在一开始的 optimized-deps （依赖优化）之外，基本可以算是零编译，因此在 H5 的开发模式下，编译速度提升明显。目前 Taro 在 Vite 编译系统适配方面，优先支持了小程序、H5 和鸿蒙三端。

在使用上，为了最大限度地减少开发者的学习成本，在文件配置方面，Taro 会在底层把 Taro 配置和 Vite 配置进行对齐，开发者基本不需要去修改配置，只需要进行少量的调整即可启用新的编译模式。开发者如果想要切换为 Vite 编译系统，首先需要安装 @tarojs/vite-runner 这一依赖，并且在配置文件中进行以下配置：

export default defineConfig<'vite'>(async (merge, { command, mode }) => {
  const baseConfig: UserConfigExport<'vite'> = {
    //...
		compiler: {
	    type: 'vite',
	    vitePlugins: [vitePlugin]
	  },
		//...
  }
})

如果想要修改 Vite 的配置，Taro 鼓励开发者自行编写 Vite 插件去进行修改，目前 Taro 只预留了 modifyViteConfig 这一个 Hook，允许开发者通过 Taro 插件修改 Vite 配置。 除此之外， Taro 将不再暴露额外的 API，这样设计也能和 Vite 生态保持一致性。

从 Webpack 迁移到 Vite 的成本，主要是存量的 Taro 插件中，存在使用 Webpack Hooks 的对配置进行修改的部分，可能无法直接找到对应的 Vite 插件进行平替，这就需要社区的力量一起进行共建！

基建更新改造 —— Rust

近年来，Rust 在业界的受欢迎度不断上升，它以媲美 C/C++ 的性能和更少的历史包袱，以及卓越的安全性，收获了大量拥趸，在开源社区和商业公司中都有了大量的应用。同时，Rust 支持 WASM 和 NAPI，在前端应用和工程化领域也受到了广泛的关注。

Rust 在前端工程化领域中带来的性能和效率提升有目共睹，比如对标 Babel 的 ，对标 Webpack 、Vite 等构建工具的 、 等，他们相比原先基于 JS/TS 的竞争对手，在性能上都有了质的飞跃。

所以，从 Taro 4 开始，我们开始引入 Rust 进行包括 Taro 开发工具、编译系统等的改造，目前已经完成对 Taro doctor、Taro init 的 Rust 化，同时整体工作流已经融合了 Rust 基座，未来我们会优先将工程化的能力下沉到 Rust 中，为开发者带来更快更好的开发体验。

升级指南

1. 创建 v4.0-beta 版本项目：

# 安装 v4.0.0 的 CLI 工具
$ npm i -g @tarojs/cli@beta
# 创建项目
$ taro init taro_project

# 也可以跳过安装 CLI 工具使用 npx 创建项目
$ npx @tarojs/cli@beta init taro_project

2. 已有项目升级到最新版本：

1. 将 package.json 文件中 Taro 相关依赖修改为 4.0.0@beta 版本；
2. 重新安装依赖：如果安装失败或打开项目失败，可以删除 node_modules、yarn.lock、package-lock.json 后重新安装依赖重新尝试。

3. Breaking Changes

自 v4.0 开始，Taro 将会梳理整个项目的依赖树，并逐步升级各个包内年久失修的依赖和可能存在的漏洞等，同时考虑到 Node.js v18 以下版本已经不再受到官方支持，自该版本起会将 Node.js v18 设置为长期支持的最低 node 版本。

对于参与 Taro 项目的各位维护者来说，由于升级至 Node.js 18 版本，也不再限制工程内必须使用 pnpm@next-7 版本，可以自行升级到最新。

在 版本中，为适配低版本浏览器环境会在运行时内默认注入一些 Polyfill 依赖，这在 v4.0 中依旧会保留，但考虑到这对于绝大多数开发者意义不足，这将需要通过配置环境变量自行启用，参考如下：

// config/prod.js
module.exports = {
  env: {
    NODE_ENV: '"production"',
    SUPPORT_TARO_POLYFILL: '"enabled"', // 默认值为 disabled
  },
  // ...
}

结语

我们预计在 2024 年 Q2 发布 Taro 4 正式版，在此期间我们会根据社区反馈继续对功能进行打磨，同时完成依赖治理、文档更新等工作。 此后 Taro 3 将进入为期 1 年的维护状态，维护期仍会接收问题修复、性能优化等更新，但不会涉及重大特性更新。 最后，衷心感谢各位参与了 Taro 社区建设的同学们。你们的每一个问题、解答和建议都对项目的成长有着重大的影响，你们的贡献使得这个社区更加活跃和充满活力。Taro 4 将是一个新的开始，前路依旧漫长，期待未来我们可以一起继续推动 Taro 社区的发展，共同创造更多的可能性。

万里飞腾仍有路，莫愁四海正风尘。

彩蛋

我们在 1 月 31 日下午举行了一场线上直播活动，主要介绍了 Taro 4.0 Beta 版本的重大特性，并进行了简单的操作演示与互动。如果错过了直播的朋友们，可以观看回放视频：