老规矩，小手动起来~点赞关注不迷路！
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中文文档专栏，本人目前正在翻译整理，关注我，有最新的翻译文档会第一时间通知你！
（本文完）
励志前端小黑哥，全网唯一账号！
关注我，带你了解更多前端知识！