老规矩,小手动起来~点赞关注不迷路!
esbuild简单介绍
esbuild
为了突破了JavaScript
语言的瓶颈,采用了Go
语言编写,构建速度与同代码量下的webpack
对比提升在10
倍以上,开创了构建工具性能的新时代。
它的中文文档,本人正在不断的更新完善中,欢迎大家关注阅读!
Supported by: Build
此功能允许您在打包时用一个包替换另一个包。以下示例将包oldpkg
替换为包newpkg
:
esbuild app.js --bundle --alias:oldpkg=newpkg
这些替换首先会发生在esbuild
所有的路径解析逻辑之前。此功能的一个使用场景是使用浏览器兼容包替换仅Node环境可使用的包,从而替换那些您无法控制的第三方代码,。
请注意,当使用Alias
替换导入路径时,生成的导入路径将在工作目录中解析,而不是在包含具有导入路径的源文件的目录中解析。如果需要,可以使用Working directory
功能设置esbuild
所使用的工作目录。
Supported by: Build
此功能控制如何解析package.json
中的exports
字段。可以使用conditions
设置添加自定义条件。您可以根据需要指定任意多个条件,这完全取决于包的作者。Node
目前只推荐使用development
和production
的自定义条件。以下是添加自定义条件custom1
和custom2
的示例:
esbuild src/app.js --bundle --conditions=custom1,custom2
contitions
允许您在不同的情况下将相同的import
路径重定向到不同的文件位置。包含条件和路径的重定向Map
存储在包的package.json
文件的exports
字段中。例如,下面这个例子将使用import
和required
条件将require('pkg/foo')
重新映射到pkg/required.cjs
,并将import 'pkg/foo'
导入映射到pkg/imported.mjs
:
{
"name": "pkg",
"exports": {
"./foo": {
"import": "./imported.mjs",
"require": "./required.cjs",
"default": "./fallback.js"
}
}
}
conditions
配置按照它们在JSON
文件中出现的顺序进行检查。所以上面的例子有点像下面这个流程:
if (importPath === './foo') {
if (conditions.has('import')) return './imported.mjs'
if (conditions.has('require')) return './required.cjs'
return './fallback.js'
}
默认情况下,有五种具有特殊含义的条件内置到esbuild
中,并且不能禁用:
这种情况始终处于激活状态。它旨在排在最后,并允许您在没有其他条件适用时提供后备方案。当您在node
中以本地方式运行代码时,此条件也处于活动状态。
只有当导入路径来自ESM
的import
语句或import()
表达式时,此条件才处于活动状态。它可用于提供ESM
特定的代码。当您在node
中以本地方式运行代码时(但仅在ESM
上下文中),此条件也处于活动状态。
只有当导入路径来自CommonJS
的require()
调用时,此条件才处于活动状态。它可以用来提供CommonJS
特定的代码。当您在node
中以本地方式运行代码时(但仅在CommonJS
上下文中),此条件也是活动的。
只有当esbuild
的platform
参数设置为browser
时,此条件才处于活动状态。它可以用于提供特定于浏览器的代码。当您在node
中以本地方式运行代码时,此条件不处于活动状态。
只有当esbuild
的platform
参数设置为node
时,此条件才处于活动状态。它可以用于提供特定的nodejs
代码。当您在node
中以本地方式运行代码时,此条件也处于活动状态。
当platform
设置为browser
或node
且未配置自定义条件时,还会自动包含以下条件。如果配置了任何自定义条件(甚至是空列表),则此条件将不再自动包含:
此条件可用于告诉esbuild
为给定的import
路径选择合适的ESM
变体,以便在打包时提供更好的树抖动tree shaking
。当您在node
中以本地方式运行代码时,此条件不处于活动状态。它是esbuild打包器特有的,灵感来源源于Webpack
。
请注意,当您使用require
和import
条件时,您的包可能会多次出现在打包文件中!这是一个小问题,除了导致打包文件膨胀之外,可能会由于代码状态的重复副本而导致错误。这通常被称为双包危害。
避免双包危害
的一种方法是将所有代码作为CommonJS
放入require
条件中,并使导入条件仅为一个简单的ESM
包装器,该包装器在包上调用require
,并使用ESM
语法重新导出包。然而,这种方法不能提供良好的树抖动,因为esbuild
不会对CommonJS
模块进行树抖动。
避免双包危害
的另一种方法是使用打包器特定的module
条件来指导打包器始终加载包的ESM
版本,同时让node
始终回退到包的CommonJS
版本。import
和module
都用于ESM
,但与import
不同的是,即使使用require
调用加载了import
路径,module
条件也始终处于活动状态。这在打包器中很好地工作,因为打包器支持使用require
加载ESM
,但它不能与node
一起工作,因为node
故意不使用require
实现加载ESM
。
笔者根据esbuild
文档搭建了一套简洁的ts
开发脚手架工程,编译速度非常快!脚手架还整合了eslint
,另一篇文章还附带了调试教程,需要的朋友看这里:esbuild配合vscode搭建的ts开发环境,这编译速度,真香
另外,esbuild中文文档专栏,本人目前正在翻译整理,关注我,有最新的翻译文档会第一时间通知你!
(本文完)
励志前端小黑哥,全网唯一账号!
关注我,带你了解更多前端知识!