关于javascript:新一代的编译工具-SWC

最近前端圈掀起了一阵 rust 风，但凡能用 rust 重写的前端工具就用 rust 重写，明天介绍的工具就是通过 rust 实现的 bable：swc，一个将 ES6 转化为 ES5 的工具。

而且在 swc 的官网，很直白说本人和 babel 对标，swc 和 babel 命令能够互相替换，并且大部分的 babel 插件也曾经实现。

应用 rust 的一个劣势就是快，比方咱们之前的一个我的项目，将 babel 替换成 swc 后，编译速度从原来的 7 秒晋升到了 1 秒，效率间接爆炸。

上手

swc 与 babel 一样，将命令行工具、编译外围模块分化为两个包。

• @swc/cli 相似于 @babel/cli;
• @swc/core 相似于 @babel/core;

npm i -D @swc/cli @swc/core

通过如下命令，能够将一个 ES6 的 JS 文件转化为 ES5。

npx swc source.js -o dist.js

上面是 source.js 的代码：

const start = () => {console.log('app started')
}

代码中囊括了 ES6 的两个个性，const 申明 和 箭头函数。通过 swc 转化后，这两个个性别离被转化成了 var 申明 和 function 匿名函数。

配置文件

swc 与 babel 一样，反对相似于 .babelrc 的配置文件：.swcrc，配置的格局为 JSON。

{
  "jsc": { // 编译规定
    "target": "es5", // 输入 js 的标准
    "parser": {
      // 除了 ecmascript，还反对 typescript
      "syntax": "ecmascript",
      // 是否解析 jsx，对应插件 @babel/plugin-transform-react-jsx
      "jsx": false,
      // 是否反对装璜器，对应插件 @babel/plugin-syntax-decorators
      "decorators": false,
      // 是否反对动静导入，对应插件 @babel/plugin-syntax-dynamic-import
      "dynamicImport": false,
      // ……
      // babel 的大部分插件都能在这里找到对应配置
    },
    "minify": {}, // 压缩相干配置，须要先开启压缩},
  "env": { // 编译后果相干配置
    "targets": { // 编译后果须要适配的浏览器
      "ie": "11" // 只兼容到 ie 11
    },
    "corejs": "3" // corejs 的版本
  },
  "minify": true // 是否开启压缩
}

babel 的插件零碎被 swc 整合成了 jsc.parser 内的配置，基本上大部分插件都能关照到。而且，swc 还继承了压缩的能力，通过 minify 属性开启，jsc.minify 用于配置压缩相干的规定，更具体的配置可查看文档。

Node APIs

通过在 node.js 代码中，导入 @swc/core 模块，能够在 node.js 中调用 api 间接进行代码的编译，这对 CLI 工具的开发来说是惯例操作。

// swc.mjs
import {readFileSync} from 'fs'
import {transform} from '@swc/core'

const run = async () => {const code = readFileSync('./source.js', 'utf-8')
    const result = await transform(code, {filename: "source.js",})
  // 输入编译后代码
  console.log(result.code)
}

run()

打包代码

除了将代码本义，swc 还提供了一个繁难的打包能力。咱们新建一个 src 文件夹，在外面新建两个文件：index.js、utils.js。

// src/index.js
import {log} from './utils.js'
const start = () => log('app started')
start()

// src/utils.js
export const log = function () {console.log(...arguments)
}
export const errorLog = function () {console.error(...arguments)
}

能够看到 index.js 导入了 utils.js 中的一个办法，而后咱们新建一个 spack.config.js 文件，该文件是 swc 打包的配置文件。

// spack.config.js
module.exports = {
  entry: {
    // 打包的入口
    web: __dirname + "/src/index.js",
  },
  output: {
    // 打包后输入的文件夹
    path: __dirname + "/dist",
  },
};

而后在命令行运行：

$ npx spack

打包胜利后，会在 dist 目录输入一个 web.js 文件。

能够看到，不仅将 index.js、utils.js 打包成了一个文件，还进行了 tree shaking，将 utils.js 中没有应用的 errorLog 办法删掉了。

能不能用？

babel 毕竟通过了这么多年的倒退，不论是 bug 输了，还是社区活跃度都远远优于 swc。所以，如果是小产品试水还是能够试一下 swc 的，旧我的项目如果曾经应用了 babel 还是不倡议进行迁徙。

在应用的过程，还是发现了一些小问题。比方，如果我应用了 async function，swc 会主动导入 regenerator-runtime 模块。

// 编译前，有个 async 办法
const start = async () => {console.log('app started')
}

调用 swc 编译后，代码如下：

这个后果看起来是没问题的，然而 swc 与 babel 相似，也有 helpers（@swc/helpers），同时提供了 externalHelpers 开关，如果把 externalHelpers 设置为 true，swc 会将一些工具类，通过模块的模式导入。

// .swcrc
{
  "jsc": {"externalHelpers": true}
}

而 externalHelpers 的默认值是 false，那这个时候，regenerator-runtime，到底是通过模块的模式导入，还是把整个代码写入到文件？

swc 正好有个 [issue [https://github.com/swc-projec…]](https://github.com/swc-projec…) 在探讨这个问题。

除了下面说的这个问题，其实还有一点，就是作者感觉之前的架构有问题，正在加紧重写 2.0 版本，感觉能够期待一下，另外提一句，swc 的作者是一个 97 年的韩国小哥，目前大学都还没毕业，最初我也只能说一句：牛逼！