Taro 2.0：拥抱社区，拥抱变化

时间 2020-01-14

标签 taro 2.0 拥抱社区变化繁體版

原文原文链接

缘起

Taro 1.x 版本自去年 9 月份发布以来，已经陪伴你们度过了一年多的时间，在此期间 Taro 一直保持高速成长，发布了多个具备重大意义的版本，让 Taro 成为现在一个功能完善，拥有众多忠实拥趸的多端统一开发框架。css

尽管 Taro 一直保持超高的迭代速度，Taro 的总体架构设计没有发生太大变化，这让 Taro 在这个时刻在变化的时代稍显佛系，且对于一个时刻想要突破本身的技术团队来讲，常规性质的维护工做，显然没法安抚咱们躁动的心，毕竟人的梦想，是永远不会中止的，因此咱们决定启动一系列的颠覆式重构设计。html

2.0

咱们首先从 CLI 开始入手进行改造，你们都知道，原来 Taro CLI 的编译构建系统是自研的，整个构建系统逻辑复杂，要考虑的边际条件众多，这就致使了如下问题：前端

维护困难，每次须要新增一个功能，例如支持解析 Markdown 文件，就须要直接改动 CLI，不够灵活
难以共建，CLI 的代码很是复杂，并且逻辑分支众多，让不少想要一块儿共建的人难以入手
可扩展性偏低，自研的构建系统，设计之初没有考虑到后续的扩展性，致使开发者想要添加自定义的功能无从下手

基于以上问题，咱们决定使用 Webpack 来实现编译构建，因而诞生了 2.0。webpack

Taro 2.0 的 CLI 将会变得很是轻量，只会作区分编译平台、处理不一样平台编译入参等操做，随后再调用对应平台的 runner 编译器 作代码编译操做，而原来大量的 AST 语法操做将会改形成 Webpack Plugin 以及 Loader，交给 Webpack 来处理。ios

相较于旧的构建系统，新的小程序编译带来了如下优点：git

利于维护，大量的逻辑交由 Webpack 来处理，咱们只须要维护一些插件
更加稳定，相较于自研的构建系统，新的构建会更加稳定，下降一些奇怪错误的出现几率
可扩展性强，能够经过自行加入 Webpack Loader 与 Plugin 的方式作本身想要的扩展
各端编译统一，接入 Webpack 后，Taro 各端的编译配置能够实现很是大程度的统一

能够看到新的构建系统会有很大的进步。同时，更重要的是，基于 Webpack，咱们能够在小程序中尝试更多的特性与技术，例如经过 tree shaking) 来优化代码包大小等等，让小程序开发更加与业界发展同步，让 Taro 更加拥抱社区。github

Migrate to 2.0

编译配置调整

2.0 总体上与 1.0 是彻底兼容的，可是在基于 Webpack 重构后，咱们对部分编译配置作了优化调整，因此若是想要将基于 1.x 的旧项目迁移至 2.0，首先须要对编译配置进行调整。web

const config = {
  projectName: 'taro-framework',
  date: '2019-11-2',
  designWidth: 750,
  deviceRatio: {
    640: 2.34 / 2,
    750: 1,
    828: 1.81 / 2
  },
  sourceRoot: 'src',
  outputRoot: 'dist',
  // babel、csso、uglify 等配置从 plugins 配置中移出来
  babel: {
    sourceMap: true,
    presets: [['env', { modules: false }]],,
    plugins: [
      'transform-decorators-legacy',
      'transform-class-properties',
      'transform-object-rest-spread'
    ]
  },
  // 小程序配置从 weapp 改成 mini，能够删掉不少小配置
  mini: {
    webpackChain (chain, webpack) {},
    cssLoaderOption: {},
    postcss: {
      pxtransform: {
        enable: true,
        config: {}
      },
      url: {
        enable: true,
        config: {
          limit: 10240 // 设定转换尺寸上限
        }
      }
    }
  },
  // 能够删掉不少小配置
  h5: {
    publicPath: '/',
    staticDirectory: 'static',
    webpackChain (chain, webpack) {},
    postcss: {
      autoprefixer: {
        enable: true,
        config: {
          browsers: [
            'last 3 versions',
            'Android >= 4.1',
            'ios >= 8'
          ]
        }
      }
    }
  }
}

module.exports = function (merge) {
  if (process.env.NODE_ENV === 'development') {
    return merge({}, config, require('./dev'))
  }
  return merge({}, config, require('./prod'))
}

具体编译配置请参考编译配置文档。shell

异步编程调整

Taro 2.0 中开启 async functions 支持再也不须要安装 @tarojs/async-await，而是直接经过 babel 插件来得到支持。npm

在项目根目录下安装包 babel-plugin-transform-runtime 和 babel-runtime。

$ yarn add babel-plugin-transform-runtime --dev
$ yarn add babel-runtime

随后修改项目 babel 配置，配置插件 babel-plugin-transform-runtime。

babel: {
  sourceMap: true,
  presets: [['env', { modules: false }]],
  plugins: [
    'transform-decorators-legacy',
    'transform-class-properties',
    'transform-object-rest-spread',
    ['transform-runtime', {
      "helpers": false,
      "polyfill": false,
      "regenerator": true,
      "moduleName": 'babel-runtime'
    }]
  ]
}

新特性尝鲜

在基于 Webpack 改造后带来全面提高的同时，2.0 也为咱们带来了如下新的特性。

主编译流程钩子

在 2.0 中，CLI 编译的主流程已经基于 Tapable 进行改造，而且对外暴露了 hooks 以供使用，在 Taro 编译配置中能够经过 plugins 来配置编译过程插件，调用这些 hooks 来实现本身的需求。

目前编译主流程暴露了两个钩子 beforeBuild 和 afterBuild，其中，beforeBuild 将在总体编译前触发，能够获取到编译的相关配置，同时也能进行修改；afterBuild 将在 Webpack 编译完后执行，能够获取到编译后的结果。具体使用方式以下。

首先定义一个插件

class BuildPlugin {
  apply (builder) {
    builder.hooks.beforeBuild.tap('BuildPlugin', (config) => {
      console.log(config)
    })

    builder.hooks.afterBuild.tap('BuildPlugin', (stats) => {
      console.log(stats)
    })
  }
}

接下来在 plugins 字段中进行配置

const config = {
  ...
  plugins: [
    new BuildPlugin()
  ]
  ...
}

为小程序编译添加 Loader

咱们有时候可能会面临在小程序中展现 Markdown 语法文件的需求，在 WEB 开发的时候咱们能够借助 Webpack 及其 Loader，实现直接引入 md 文件并读取其内容，而在小程序开发中，经过借助 Taro 2.0，咱们也能很轻松地实现这一需求。

通常咱们会以以下的方式，来引入一个 .md 文件。

import mdTxt from '../../some_markdown.md'

而 .md 文件默认是不能直接被识别的，咱们须要经过配置相应的 Loader 来实现对这类文件的加载解析，在 Taro 中能够经过 mini.webpackChain 来为小程序配置自定义 Webpack 配置，咱们也能够经过它来配置 Loader。

const config = {
  mini: {
    webpackChain (chain) {
      chain.merge({
        module: {
          rule: {
            myloader: {
              test: /\.md$/,
              use: [{
                loader: 'raw-loader',
                options: {}
              }]
            }
          }
        }
      })
    }
  }
}

为小程序编译添加 Plugin

当咱们要把打包后的小程序进行发布的时候，可能会遇到小程序过大的问题，那么咱们确定迫切但愿能够看到究竟是哪些文件的大小形成了这个影响，咱们能够经过使用 webpack-bundle-analyzer 插件对打包体积进行分析。

在 mini.webpackChain 中添加以下配置。

const config = {
  mini: {
    webpackChain (chain, webpack) {
      chain.plugin('analyzer')
        .use(require('webpack-bundle-analyzer').BundleAnalyzerPlugin, [])
    }
  }
}

在运行以后，咱们就能在浏览器里看到以下分析效果。

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。

将来与展望

正如前文所提到的，Taro 2.0 只是一个开始。

在 10 年代最后一场 GMTC 全球大前端技术大会上，Taro 团队向你们展现了小程序跨框架开发的探索与实践的艰辛旅程，同时也提早曝光了正在紧密开发中的 Taro Next。

那是一个彻底区别于以往的版本，一条与如今 Taro 大相径庭的道路，预示着 Taro 正在革本身的命。

节物风光不相待，桑田碧海须臾改。

20 年代呼啸而来，下一个 10 年，不少框架都会死去，不少技术也会焕然而生，没有什么是不变的，惟一不变的只有变化，咱们能作的也只能是拥抱变化。

欢迎关注凹凸实验室博客：aotu.io

或者关注凹凸实验室公众号（AOTULabs），不定时推送文章：