新一代的编译工具|新一代的编译工具 SWC
最近前端圈掀起了一阵 rust 风,凡是能用 rust 重写的前端工具就用 rust 重写,今天介绍的工具就是通过 rust 实现的 bable:swc,一个将 ES6 转化为 ES5 的工具。
而且在 swc 的官网,很直白说自己和 babel 对标,swc
和 babel
命令可以相互替换,并且大部分的 babel 插件也已经实现。
文章图片
【新一代的编译工具|新一代的编译工具 SWC】使用 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 年的韩国小哥,目前大学都还没毕业,最后我也只能说一句:牛逼!
推荐阅读
- 热闹中的孤独
- JAVA(抽象类与接口的区别&重载与重写&内存泄漏)
- 放屁有这三个特征的,请注意啦!这说明你的身体毒素太多
- 一个人的旅行,三亚
- 布丽吉特,人生绝对的赢家
- 慢慢的美丽
- 尽力
- 一个小故事,我的思考。
- 家乡的那条小河
- 《真与假的困惑》???|《真与假的困惑》??? ——致良知是一种伟大的力量