文章目录
哈喽,大家好!我是「励志前端小黑哥」,我带着最新发布的文章又来了!
老规矩,小手动起来~点赞关注不迷路!
esbuild简单介绍
esbuild
为了突破了JavaScript
语言的瓶颈,采用了Go
语言编写,构建速度与同代码量下的webpack
对比提升在10
倍以上,开创了构建工具性能的新时代。
它的中文文档,本人正在不断的更新完善中,欢迎大家关注阅读!
平台(Platform)
Supported by: Transform | Build
默认情况下,esbuild
的bundler
被配置为生成用于浏览器的代码。如果打包代码打算在node
中运行,则应将平台设置为node
:
esbuild app.js --bundle --platform=node
当platform
设置为浏览器broswer
(默认值)时:
启用打包时,默认输出格式设置为
iife
,它将生成的JavaScript
代码包裹在一个立即执行的函数表达式中,以防止变量泄漏到全局范围中。如果一个包在其
package.json
文件中为browser
字段指定了映射,esbuild
将使用该映射以浏览器友好的版本替换特定的文件或模块。例如,一个包可能使用path-browserify
替换path
。main
字段可设置为browser
、module
、main
,有一些额外的特殊行为:如果包提供了module
和main
入口点,但不是browser
入口点,则如果使用require()
导入包,则使用main
而不是module
。这种方式提高了导出函数与CommonJS
模块(通过将函数分配给module.exports
)的兼容性。如果要禁用此额外的特殊行为,可以将main
字段显式设置为browser、module、main
。conditions
选项会自动包括browser
条件。这将改变package.json
文件中exports
字段的解释方式,使其更倾向特定浏览器的代码。如果未配置自定义的
conditions
,则还会包括Webpack特定的module
条件。包作者使用module
条件为CommonJS
文件提供一个tree shaking
的ESM
替代方案,而不会产生“双包危害”。您可以通过显式配置某些自定义条件(甚至是空列表)来防止包含module
条件。使用
build API
时,如果启用了所有的压缩选项,则所有process.env.NODE_env
表达式将自动定义为production
,否则定义为development
。只有在尚未定义process.env
和process.env.NODE_env
时才会发生这种情况。这种替换对于避免基于React
的代码立即崩溃是必要的(因为process
是node API
,而不是web API
)。字符序列
</script>
将在JavaScript
代码中转义,字符序列</style>
将在CSS
代码中转义。这是在您将esbuild
的输出直接内联到HTML
文件中的情况下完成的。可以使用esbuild
的supported
特性来禁用此功能,将内联脚本(用于JavaScript)和内联样式(用于CSS)设置为false
即可。
当platform
设置为node
时:
启用
bundle
后,默认输出格式设置为cjs
,代表CommonJS
(node
使用的模块格式)。使用export
语句的ES6
样式导出将转换为CommonJS
导出对象上的getter
。所有内置的
node
模块(如fs
)都会自动标记为external
,这样之后当bundler
试图打包它们时,它们就不会导致错误。main fields
会被设置为main,module
。这意味着同时提供module
和main
的包可能不会发生tree shaking
,因为tree shaking
只适用于ECMAScript
模块,但不适用于CommonJS
模块。
不幸的是,有些包错误地将module
视为“浏览器代码”,而不是“ECMAScript模块代码”,所以此默认行为需要兼容性。如果您想启用tree shaking
并且知道这样做是安全的,您可以手动将main fields
设置配置为module,main
。conditions
设置自动包括node
条件。这将改变package.json
文件中exports
字段的解释方式,使其更喜欢特定于node
的代码。如果未配置自定义的
conditions
,则还会包括Webpack特定的module
条件。包作者使用module
条件为CommonJS
文件提供一个tree shaking
的ESM
替代方案,而不会产生“双包危害”。您可以通过显式配置某些自定义条件(甚至是空列表)来防止包含module
条件。当
format
设置为cjs
但入口点为ESM
时,esbuild
将为所有的命名export
添加特殊注释,以允许使用ESM
语法从生成的CommonJS
文件中导入这些命名export
。Node
的文档提供了有关Node检测CommonJS命名导出的更多信息。binary loader
加载器将利用node
内置的Buffer.from API
,将包中嵌入的base64
数据解码为Uint8Array
。这比esbuild
在其他情况下所能做的更快,因为它是由本机代码中的node
实现的。
当platform
设置为neutral
时:
启用
bundle
后,默认输出格式format
设置为esm
,它使用ECMAScript 2015
(即ES6
)引入的导出语法。如果此默认设置不合适,则可以更改输出格式。默认情况下,
main fields
设置为空。如果您想使用npm风格的包,您可能需要将其配置为其他内容,例如node使用的标准主字段的main
。conditions
设置不会自动包括任何特定平台的值。
结语
笔者根据esbuild
文档搭建了一套简洁的ts
开发脚手架工程,编译速度非常快!脚手架还整合了eslint
,另一篇文章还附带了调试教程,需要的朋友看这里:esbuild配合vscode搭建的ts开发环境,这编译速度,真香
另外,esbuild中文文档专栏,本人目前正在翻译整理,关注我,有最新的翻译文档会第一时间通知你!
(本文完)
励志前端小黑哥,全网唯一账号!
关注我,带你了解更多前端知识!