⚡️ Speed up your Webpack build with esbuild
npm install esbuild-loaderSpeed up your Webpack build with esbuild! 🔥
_esbuild_ is a JavaScript bundler written in Go that supports blazing fast ESNext & TypeScript transpilation and JS minification.
_esbuild-loader_ lets you harness the speed of esbuild in your Webpack build by offering faster alternatives for transpilation (eg. babel-loader/ts-loader) and minification (eg. Terser)!
> [!TIP]
> Are you using TypeScript with Node.js?
>
> Supercharge your Node.js with TypeScript support using _tsx_!
>
> _tsx_ is a simple, lightweight, and blazing fast alternative to ts-node.
>
> → Learn more about _tsx_
Already a sponsor? Join the discussion in the Development repo!
``bash`
npm i -D esbuild-loader
To leverage esbuild-loader in your Webpack configuration, add a new rule for esbuild-loader matching the files you want to transform, such as .js, .jsx, .ts, or .tsx. Make sure to remove any other loaders you were using before (e.g. babel-loader/ts-loader).
Here's an example of how to set it up in your webpack.config.js:
`diff.js
module.exports = {
module: {
rules: [
- // Transpile JavaScript
- {
- test: /\.js$/,
- use: 'babel-loader'
- },
-
- // Compile TypeScript
- {
- test: /\.tsx?$/,
- use: 'ts-loader'
- },
+ // Use esbuild to compile JavaScript & TypeScript
+ {
+ // Match , .jsx, .ts or .tsx files
+ test: /\.[jt]sx?$/,
+ loader: 'esbuild-loader',
+ options: {
+ // JavaScript version to compile to
+ target: 'es2015'
+ }
+ },
// Other rules...
],
},
}
`
In this setup, esbuild will automatically determine how to handle each file based on its extension:
- .js files will be treated as JS (no JSX allowed).jsx
- as JSX.ts
- as TS (no TSX allowed).tsx
- as TSX
If you want to force a specific loader on different file extensions (e.g. to allow JSX in .js files), you can use the loader option:
`diff.js
{
test: /\.js$/,
loader: 'esbuild-loader',
options: {
+ // Treat files as .jsx files
+ loader: 'jsx',
// JavaScript version to transpile to
target: 'es2015'
}
}
`
esbuild-loader can be used in-place of babel-loader to transpile new JavaScript syntax into code compatible with older JavaScript engines.
While this ensures your code can run smoothly across various environments, note that it can bloat your output code (like Babel).
The default target is esnext, which means it doesn't perform any transpilations.
To specify a target JavaScript engine that only supports ES2015, use the following configuration in your webpack.config.js:
`diff`
{
test: /\.jsx?$/,
loader: 'esbuild-loader',
options: {
+ target: 'es2015',
},
}
For a detailed list of supported transpilations and versions, refer to the esbuild documentation.
esbuild-loader can be used in-place of ts-loader to compile TypeScript.
`js.ts
({
// or .tsx files`
test: /\.tsx?$/,
loader: 'esbuild-loader'
})
> [!IMPORTANT]
> It's possible to use loader: 'tsx' for both .ts and .tsx files, but this could lead to unexpected behavior as TypeScript and TSX do not have compatible syntaxes.
>
> → Read more
#### tsconfig.jsontsconfig.json
If you have a file in your project, esbuild-loader will automatically load it.
If it's under a custom name, you can pass in the path via tsconfig option:`diff`
{
test: /\.tsx?$/,
loader: 'esbuild-loader',
options: {
+ tsconfig: './tsconfig.custom.json',
},
},
> Behind the scenes: get-tsconfig is used to load the tsconfig, and to also resolve the extends property if it exists.
The tsconfigRaw option can be used to pass in a raw tsconfig object, but it will not resolve the extends property.
##### Caveats
- esbuild only supports a subset of tsconfig options (see TransformOptions interface).
- Enable isolatedModules to avoid mis-compilation with features like re-exporting types.
- Enable esModuleInterop to make TypeScript's type system compatible with ESM imports.
- Features that require type interpretation, such as emitDecoratorMetadata and declaration, are not supported.
→ Read more about TypeScript Caveats
#### tsconfig.json Pathstsconfig.json#paths
Use tsconfig-paths-webpack-plugin to add support for .
Since esbuild-loader only transforms code, it cannot aid Webpack with resolving paths.
#### Type-checking
esbuild does not type check your code. And according to the esbuild FAQ), it will not be supported.
Consider these type-checking alternatives:
- Using an IDEs like VSCode or WebStorm that has live type-checking built in
- Running tsc --noEmit to type checkfork-ts-checker-webpack-plugin
- Integrating type-checking to your Webpack build as a separate process using
In webpack.config.js:
`diff
+ const { EsbuildPlugin } = require('esbuild-loader')
module.exports = {
...,
+ optimization: {
+ minimizer: [
+ new EsbuildPlugin({
+ target: 'es2015' // Syntax to transpile to (see options below for possible values)
+ })
+ ]
+ },
}
`
> [!TIP]
> Utilizing the target option allows for the use of newer JavaScript syntax, enhancing minification effectiveness.
Webpack's DefinePlugin can replaced with EsbuildPlugin to define global constants. This could speed up the build by removing the parsing costs associated with the DefinePlugin.
In webpack.config.js:
`diff
- const { DefinePlugin } = require('webpack')
+ const { EsbuildPlugin } = require('esbuild-loader')
module.exports = {
// ...,
plugins:[
- new DefinePlugin({
- 'process.env.NODE_ENV': JSON.stringify(process.env.NODE_ENV),
- })
+ new EsbuildPlugin({
+ define: {
+ 'process.env.NODE_ENV': JSON.stringify(process.env.NODE_ENV),
+ },
+ }),
]
}
`
> [!WARNING]
> The plugin's define option does not work with eval-based devtools (e.g., eval, eval-source-map). This is because eval devtools wrap module code in eval() strings, and esbuild's define cannot replace identifiers inside string literals. If you need to use define with eval devtools, use the loader's define option instead, which transforms files before bundling.
If your project does not use TypeScript, JSX, or any other syntax that requires additional configuration beyond what Webpack provides, you can use EsbuildPlugin for transpilation instead of the loader.
It will be faster because there's fewer files to process, and will produce a smaller output because polyfills will only be added once for the entire build as opposed to per file.
To utilize esbuild for transpilation, simply set the target option on the plugin to specify which syntax support you want.
Depending on your setup, there are two ways to minify CSS. You should already have CSS loading setup using css-loader.
file, you can replace CSS minification plugins like css-minimizer-webpack-plugin with the EsbuildPlugin.Assuming the CSS is extracted using something like MiniCssExtractPlugin, in
webpack.config.js:`diff
const { EsbuildPlugin } = require('esbuild-loader')
const MiniCssExtractPlugin = require('mini-css-extract-plugin'); module.exports = {
// ...,
optimization: {
minimizer: [
new EsbuildPlugin({
target: 'es2015',
+ css: true // Apply minification to CSS assets
})
]
},
module: {
rules: [
{
test: /\.css$/i,
use: [
MiniCssExtractPlugin.loader,
'css-loader'
]
}
],
},
plugins: [
new MiniCssExtractPlugin()
]
}
`
$3
If your CSS is not emitted as a
.css file, but rather injected with JavaScript using something like style-loader, you can use the loader for minification.
In
webpack.config.js:`diff
module.exports = {
// ..., module: {
rules: [
{
test: /\.css$/i,
use: [
'style-loader',
'css-loader',
+ {
+ loader: 'esbuild-loader',
+ options: {
+ minify: true,
+ },
+ },
],
},
],
},
}
`Bring your own esbuild (Advanced)
esbuild-loader comes with a version of esbuild it has been tested to work with. However, esbuild has a frequent release cadence, and while we try to keep up with the important releases, it can get outdated.
To work around this, you can use the
implementation option in the loader or the plugin to pass in your own version of esbuild (eg. a newer one).> [!WARNING]
> ⚠esbuild is not stable yet and can have dramatic differences across releases. Using a different version of esbuild is not guaranteed to work.
`diff
+ const esbuild = require('esbuild') module.exports = {
// ...,
module: {
rules: [
{
test: ...,
loader: 'esbuild-loader',
options: {
// ...,
+ implementation: esbuild,
},
},
],
},
}
`Setup examples
If you'd like to see working Webpack builds that use esbuild-loader for basic JS, React, TypeScript, Next.js, etc. check out the examples repo:⚙️ Options
$3
The loader supports all Transform options from esbuild.devtool. sourcemap/sourcefile options are ignored.
- The root tsconfig.json is automatically detected for you. You don't need to pass in tsconfigRaw unless it's in a different path.
Here are some common configurations and custom options:
#### tsconfig
Type:
stringPass in the file path to a custom tsconfig file. If the file name is
tsconfig.json, it will automatically detect it.#### target
Type:
string | ArrayDefault:
'es2015'The target environment (e.g.
es2016, chrome80, esnext).Read more about it in the esbuild docs.
#### loader
Type:
'js' | 'jsx' | 'ts' | 'tsx' | 'css' | 'json' | 'text' | 'base64' | 'file' | 'dataurl' | 'binary' | 'default'Default:
'default'The loader to use to handle the file. See the type for possible values.
By default, it automatically detects the loader based on the file extension.
Read more about it in the esbuild docs.
#### jsxFactory
Type:
stringDefault:
React.createElementCustomize the JSX factory function name to use.
Read more about it in the esbuild docs.
#### jsxFragment
Type:
stringDefault:
React.FragmentCustomize the JSX fragment function name to use.
Read more about it in the esbuild docs.
#### implementation
Type:
{ transform: Function }_Custom esbuild-loader option._
Use it to pass in a different esbuild version.
$3
The loader supports all Transform options from esbuild.
#### target
Type:
string | ArrayDefault:
'esnext'Target environment (e.g.
'es2016', ['chrome80', 'esnext'])Read more about it in the esbuild docs.
Here are some common configurations and custom options:
#### format
Type:
'iife' | 'cjs' | 'esm'Default:
-
iife if both of these conditions are met:
- Webpack's target is set to web
- esbuild's target is not esnext
- undefined (no format conversion) otherwiseThe default is
iife when esbuild is configured to support a low target, because esbuild injects helper functions at the top of the code. On the web, having functions declared at the top of a script can pollute the global scope. In some cases, this can lead to a variable collision error. By setting format: 'iife', esbuild wraps the helper functions in an IIFE to prevent them from polluting the global.Read more about it in the esbuild docs.
#### minify
Type:
booleanDefault:
trueEnable JS minification. Enables all
minify* flags below.To have nuanced control over minification, disable this and enable the specific minification you want below.
Read more about it in the esbuild docs.
#### minifyWhitespace
Type:
booleanMinify JS by removing whitespace.
#### minifyIdentifiers
Type:
booleanMinify JS by shortening identifiers.
#### minifySyntax
Type:
booleanMinify JS using equivalent but shorter syntax.
#### legalComments
Type:
'none' | 'inline' | 'eof' | 'external'Default:
'inline'Read more about it in the esbuild docs.
#### css
Type:
booleanDefault:
falseWhether to minify CSS files.
#### include
Type:
string | RegExp | ArrayTo only apply the plugin to certain assets, pass in filters include
#### exclude
Type:
string | RegExp | ArrayTo prevent the plugin from applying to certain assets, pass in filters to exclude
#### implementation
Type:
{ transform: Function }Use it to pass in a different esbuild version.
💡 Support
For personalized assistance, take advantage of my _Priority Support_ service.
Whether it's about Webpack configuration, esbuild, or TypeScript, I'm here to guide you every step of the way!
🙋♀️ FAQ
$3
No. esbuild plugins are only available in the build API. And esbuild-loader uses the transform API instead of the build API for two reasons:
1. The build API is for creating JS bundles, which is what Webpack does. If you want to use esbuild's build API, consider using esbuild directly instead of Webpack.2. The build API reads directly from the file-system, but Webpack loaders operate in-memory. Webpack loaders are essentially just functions that are called with the source-code as the input. Not reading from the file-system allows loaders to be chainable. For example, using
vue-loader to compile Single File Components (.vue files), then using esbuild-loader to transpile just the JS part of the SFC.$3
No. The
inject option is only available in the build API. And esbuild-loader uses the transform API.However, you can use the Webpack equivalent ProvidePlugin instead.
If you're using React, check out this example on how to auto-import React in your components.
$3
No. If you really need them, consider porting them over to a Webpack loader.And please don't chain
babel-loader and esbuild-loader. The speed gains come from replacing babel-loader.$3
Running esbuild as a standalone bundler vs esbuild-loader + Webpack are completely different:
- esbuild is highly optimized, written in Go, and compiled to native code. Read more about it here.
- esbuild-loader is handled by Webpack in a JS runtime, which applies esbuild transforms per file. On top of that, there's likely other loaders & plugins in a Webpack config that slow it down.Using a JS runtime introduces a bottleneck that makes reaching those speeds impossible. However, esbuild-loader can still speed up your build by removing the bottlenecks created by
babel-loader, ts-loader`, Terser, etc.#### tsx
Node.js enhanced with esbuild to run TypeScript and ESM.
#### instant-mocha
Webpack-integrated Mocha test-runner with Webpack 5 support.
#### webpack-localize-assets-plugin
Localize/i18nalize your Webpack build. Optimized for multiple locales!