迁移至 Taro 2.x
Taro 2.0 整体上与 1.0 是完全兼容的,迁移并不困难,本指南将指导你如何进行从 Taro 1.x 到 Taro 2.x 的迁移工作。
#
更新 Taro CLI 和依赖版本你可以根据自己的实际情况选择升级全局的 Taro 版本或者仅为你的某一个项目升级。
#
全局 CLI 升级如果你的 Taro CLI 以全局方式安装,并且你希望升级到 Taro 2.0 需要执行以下命令:
之后在你的项目目录里运行以下命令来升级依赖:
#
单独为某一个项目升级这样做的好处是全局的 Taro 版本还是 1.x 的,多个项目间的依赖不冲突,其余项目依然可以用旧版本开发。 如果你的项目里没有安装 Taro CLI,你需要先装一个:
然后在你的项目目录里运行以下命令来升级依赖:
@tarojs/mini-runner
依赖#
安装 Taro 2.0 新增了 @tarojs/mini-runner
作为小程序的编译依赖,所以你需要将它安装在你的项目里,运行:
#
编译配置调整Taro 2.0 对 CLI 的编译构建系统进行了重构,使用 Webpack 来实现编译构建,所以我们对部分编译配置做了优化调整。
具体编译配置请参考 编译配置文档。
#
异步编程调整Taro 2.0 中开启 async functions
支持不再需要安装 @tarojs/async-await
,而是直接通过 babel 插件来获得支持。
如果你已经在项目中安装并使用 @tarojs/async-await
包,需先将它删除。
在你的 App.jsx/tsx
里删除 import '@tarojs/async-await'
。
在项目根目录下安装包 babel-plugin-transform-runtime
和 babel-runtime
。
随后修改项目 babel 配置,配置插件 babel-plugin-transform-runtime
。
#
注意:Taro RN 依赖升级到 0.59.9在 2.0 中我们将 RN 端 React 依赖升级到 16.8.0,React Native 依赖升级到 0.59.9。主要原因:
- Google 要求所有 Google Play 应用支持 64 位 so 库,而现有 RN 0.55.4 依无法支持 64 位库,为配合 64 位升级,Taro RN 端的 React Native 依赖需要同步升级
- React 16.8.0 是第一个支持 Hook 的版本,React Native 从 0.59 版本开始支持 Hook,此前社区一直在呼吁对 RN 0.55.4 进行升级以直接支持 Hook 的写法
本次 RN 端属于无缝升级,原有的写法和配置均不变,如果使用 taro-native-shell 的,选择 0.59.9 分支即可;在原生应用集成 RN 的,需要自行升级 React Native 依赖到 0.59.9。
#
升级常见问题整理#
小程序Function(...) is not a function
#
使用 async/await 时出现报错 在升级到 2.x 后使用 async/await 语法时可能会出现如下报错
这是因为 @tarojs/mini-runner
使用的 postcss-loader
依赖了新版本的 regenerator-runtime
包,可能会与 babel-runtime
中依赖的 regenerator-runtime
版本冲突,而新版本的包无法在小程序中使用,所以导致了如上错误,解决办法是在本地自行安装 0.11.1
版本的 regenerator-runtime
包。
vendors.js
过大#
拆分的公共文件 在 2.x 中默认会抽离 4 个公共文件,分别为
runtime
: webpack 运行时入口vendors
: node_modules 中文件抽离taro
: node_modules 中 Taro 相关依赖抽离common
: 项目中业务代码公共文件抽离
由于 vendors
默认是除 Taro 相关依赖之外的所有引用的 node_modules 文件的抽离公共文件,所以如果开发人员自己引入了过多的 npm 包就会导致 vendors.js
过大,解决办法可以是尽量少用 npm 包,其二是可以自己配置更细的拆分
例如,如果引入了 lodash,由于 lodash 本身比较大,可以再自行配置 mini.webpackChain
来将 lodash 单独拆分出来,示例配置如下
随后需要再通过 mini.commonChunks
配置来添加 lodash
公共文件
这样就能将 lodash 相关依赖单独抽离到 lodash.js
中,以实现对 vendors
的拆分
#
发觉升级之后文件更大如果觉得升级到 2.x 文件更大,可以通过使用 webpack-bundle-analyzer 插件对打包体积进行分析。
首先安装 webpack-bundle-analyzer
依赖。
随后在 mini.webpackChain
中添加如下配置。
在运行之后,我们就能在浏览器里看到如下分析效果。
并且可以通过点击左侧导航中 Treemap sizes:
的 Stat
按钮,来查看每一个文件的具体依赖关系及依赖文件的大小。
#
某些组件样式失效了在升级到 2.x 后可能会遇到某些组件的样式失效了,这是因为 2.x 中默认将所有被超过 1 个文件引用的公共样式抽离到了 common
文件中,该文件默认会被 app
引入,而由于小程序组件默认不能接受公共,所以会导致样式失效,可以通过为组件配置 addGlobalClass
来解决,或者也可以通过自己配置 Webpack 禁止抽离公共样式。
自 2.1.1 开始,公共样式不再直接被 app
引入,而是会自动识别引用到公共样式的页面和组件,直接在他们的样式文件中引入公共样式,这样的话组件不需要再配置 addGlobalClass
了。
#
在 JS 中引入的图片突然变成 base64 格式在升级到 2.x 后可能会遇到在 JS 中引入的图片突然变成 base64 格式了,是因为 2.x 小程序改用 Webpack 编译后图片都会经过 url-loader
进行处理,默认 10kb 大小以下的图片(包含以下格式,png | jpg | jpeg | gif | bmp)都会被转为 base64,如果不想这么做,可以通过配置 mini.imageUrlLoaderOption 来解决