This release brings noticeable performance improvements for JS parsing and for CSS parsing and printing. Here's an example benchmark for using esbuild to pretty-print a single large minified CSS file and JS file:
Test case
Previous release
This release
4.8mb CSS file
19ms
11ms (1.7x faster)
5.8mb JS file
36ms
32ms (1.1x faster)
The performance improvements were very straightforward:
Identifiers were being scanned using a generic character advancement function instead of using custom inline code. Advancing past each character involved UTF-8 decoding as well as updating multiple member variables. This was sped up using loop that skips UTF-8 decoding entirely and that only updates member variables once at the end. This is faster because identifiers are plain ASCII in the vast majority of cases, so Unicode decoding is almost always unnecessary.
CSS identifiers and CSS strings were still being printed one character at a time. Apparently I forgot to move this part of esbuild's CSS infrastructure beyond the proof-of-concept stage. These were both very obvious in the profiler, so I think maybe I have just never profiled esbuild's CSS printing before?
There was unnecessary work being done that was related to source maps when source map output was disabled. I likely haven't observed this before because esbuild's benchmarks always have source maps enabled. This work is now disabled when it's not going to be used.
I definitely should have caught these performance issues earlier. Better late than never I suppose.
v0.15.17
Search for missing source map code on the file system (#2711)
Source maps are JSON files that map from compiled code back to the original code. They provide the original source code using two arrays: sources (required) and sourcesContent (optional). When bundling is enabled, esbuild is able to bundle code with source maps that was compiled by other tools (e.g. with Webpack) and emit source maps that map all the way back to the original code (e.g. before Webpack compiled it).
Previously if the input source maps omitted the optional sourcesContent array, esbuild would use null for the source content in the source map that it generates (since the source content isn't available). However, sometimes the original source code is actually still present on the file system. With this release, esbuild will now try to find the original source code using the path in the sources array and will use that instead of null if it was found.
Fix parsing bug with TypeScript infer and extends (#2712)
This release fixes a bug where esbuild incorrectly failed to parse valid TypeScript code that nests extends inside infer inside extends, such as in the example below:
type A<T> = {};
type B = {} extends infer T extends {} ? A<T> : never;
TypeScript code that does this should now be parsed correctly.
Use WebAssembly.instantiateStreaming if available (#1036, #1900)
Currently the WebAssembly version of esbuild uses fetch to download esbuild.wasm and then WebAssembly.instantiate to compile it. There is a newer API called WebAssembly.instantiateStreaming that both downloads and compiles at the same time, which can be a performance improvement if both downloading and compiling are slow. With this release, esbuild now attempts to use WebAssembly.instantiateStreaming and falls back to the original approach if that fails.
The implementation for this builds on a PR by @lbwa.
This improves the use of esbuild as a faster TypeScript-to-JavaScript frontend for Webpack, which has special magic comments inside new Worker() expressions that affect Webpack's behavior.
This release brings noticeable performance improvements for JS parsing and for CSS parsing and printing. Here's an example benchmark for using esbuild to pretty-print a single large minified CSS file and JS file:
Test case
Previous release
This release
4.8mb CSS file
19ms
11ms (1.7x faster)
5.8mb JS file
36ms
32ms (1.1x faster)
The performance improvements were very straightforward:
Identifiers were being scanned using a generic character advancement function instead of using custom inline code. Advancing past each character involved UTF-8 decoding as well as updating multiple member variables. This was sped up using loop that skips UTF-8 decoding entirely and that only updates member variables once at the end. This is faster because identifiers are plain ASCII in the vast majority of cases, so Unicode decoding is almost always unnecessary.
CSS identifiers and CSS strings were still being printed one character at a time. Apparently I forgot to move this part of esbuild's CSS infrastructure beyond the proof-of-concept stage. These were both very obvious in the profiler, so I think maybe I have just never profiled esbuild's CSS printing before?
There was unnecessary work being done that was related to source maps when source map output was disabled. I likely haven't observed this before because esbuild's benchmarks always have source maps enabled. This work is now disabled when it's not going to be used.
I definitely should have caught these performance issues earlier. Better late than never I suppose.
0.15.17
Search for missing source map code on the file system (#2711)
Source maps are JSON files that map from compiled code back to the original code. They provide the original source code using two arrays: sources (required) and sourcesContent (optional). When bundling is enabled, esbuild is able to bundle code with source maps that was compiled by other tools (e.g. with Webpack) and emit source maps that map all the way back to the original code (e.g. before Webpack compiled it).
Previously if the input source maps omitted the optional sourcesContent array, esbuild would use null for the source content in the source map that it generates (since the source content isn't available). However, sometimes the original source code is actually still present on the file system. With this release, esbuild will now try to find the original source code using the path in the sources array and will use that instead of null if it was found.
Fix parsing bug with TypeScript infer and extends (#2712)
This release fixes a bug where esbuild incorrectly failed to parse valid TypeScript code that nests extends inside infer inside extends, such as in the example below:
type A<T> = {};
type B = {} extends infer T extends {} ? A<T> : never;
TypeScript code that does this should now be parsed correctly.
Use WebAssembly.instantiateStreaming if available (#1036, #1900)
Currently the WebAssembly version of esbuild uses fetch to download esbuild.wasm and then WebAssembly.instantiate to compile it. There is a newer API called WebAssembly.instantiateStreaming that both downloads and compiles at the same time, which can be a performance improvement if both downloading and compiling are slow. With this release, esbuild now attempts to use WebAssembly.instantiateStreaming and falls back to the original approach if that fails.
The implementation for this builds on a PR by @lbwa.
This improves the use of esbuild as a faster TypeScript-to-JavaScript frontend for Webpack, which has special magic comments inside new Worker() expressions that affect Webpack's behavior.
Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.
Dependabot commands and options
You can trigger Dependabot actions by commenting on this PR:
- `@dependabot rebase` will rebase this PR
- `@dependabot recreate` will recreate this PR, overwriting any edits that have been made to it
- `@dependabot merge` will merge this PR after your CI passes on it
- `@dependabot squash and merge` will squash and merge this PR after your CI passes on it
- `@dependabot cancel merge` will cancel a previously requested merge and block automerging
- `@dependabot reopen` will reopen this PR if it is closed
- `@dependabot close` will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually
- `@dependabot ignore this major version` will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
- `@dependabot ignore this minor version` will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
- `@dependabot ignore this dependency` will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)
Bumps esbuild from 0.15.15 to 0.15.18.
Release notes
Sourced from esbuild's releases.
... (truncated)
Changelog
Sourced from esbuild's changelog.
... (truncated)
Commits
2953831
publish 0.15.18 to npma3ba2b2
perf release notesf0d8fdd
oops: skip source maps for improved performancee49e093
css: optimize printing quoted unescaped stringsa193324
css: improve identifier printing performance83b5580
css: pretty-print test failures2b8883c
css: improve lexer identifier parsing performancef6f8b27
js: improve lexer identifier parsing performancedecf208
restrict gc disable to not serve or watch mode2030df1
don't disable the gc with multiple entry pointsDependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting
@dependabot rebase
.Dependabot commands and options
You can trigger Dependabot actions by commenting on this PR: - `@dependabot rebase` will rebase this PR - `@dependabot recreate` will recreate this PR, overwriting any edits that have been made to it - `@dependabot merge` will merge this PR after your CI passes on it - `@dependabot squash and merge` will squash and merge this PR after your CI passes on it - `@dependabot cancel merge` will cancel a previously requested merge and block automerging - `@dependabot reopen` will reopen this PR if it is closed - `@dependabot close` will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually - `@dependabot ignore this major version` will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself) - `@dependabot ignore this minor version` will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself) - `@dependabot ignore this dependency` will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)