Commit 541d50a
chore(deps-dev): Bump esbuild from 0.15.16 to 0.15.18 (#346)
Bumps [esbuild](https://github.com/evanw/esbuild) from 0.15.16 to
0.15.18.
<details>
<summary>Release notes</summary>
<p><em>Sourced from <a
href="https://github.com/evanw/esbuild/releases">esbuild's
releases</a>.</em></p>
<blockquote>
<h2>v0.15.18</h2>
<ul>
<li>
<p>Performance improvements for both JS and CSS</p>
<p>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:</p>
<table>
<thead>
<tr>
<th>Test case</th>
<th>Previous release</th>
<th>This release</th>
</tr>
</thead>
<tbody>
<tr>
<td>4.8mb CSS file</td>
<td>19ms</td>
<td>11ms (1.7x faster)</td>
</tr>
<tr>
<td>5.8mb JS file</td>
<td>36ms</td>
<td>32ms (1.1x faster)</td>
</tr>
</tbody>
</table>
<p>The performance improvements were very straightforward:</p>
<ul>
<li>
<p>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.</p>
</li>
<li>
<p>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?</p>
</li>
<li>
<p>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.</p>
</li>
</ul>
<p>I definitely should have caught these performance issues earlier.
Better late than never I suppose.</p>
</li>
</ul>
<h2>v0.15.17</h2>
<ul>
<li>
<p>Search for missing source map code on the file system (<a
href="https://github-redirect.dependabot.com/evanw/esbuild/issues/2711">#2711</a>)</p>
<p><a href="https://sourcemaps.info/spec.html">Source maps</a> are JSON
files that map from compiled code back to the original code. They
provide the original source code using two arrays: <code>sources</code>
(required) and <code>sourcesContent</code> (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).</p>
<p>Previously if the input source maps omitted the optional
<code>sourcesContent</code> array, esbuild would use <code>null</code>
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 <code>sources</code> array and will use that instead of
<code>null</code> if it was found.</p>
</li>
<li>
<p>Fix parsing bug with TypeScript <code>infer</code> and
<code>extends</code> (<a
href="https://github-redirect.dependabot.com/evanw/esbuild/issues/2712">#2712</a>)</p>
<p>This release fixes a bug where esbuild incorrectly failed to parse
valid TypeScript code that nests <code>extends</code> inside
<code>infer</code> inside <code>extends</code>, such as in the example
below:</p>
<pre lang="ts"><code>type A<T> = {};
type B = {} extends infer T extends {} ? A<T> : never;
</code></pre>
<p>TypeScript code that does this should now be parsed correctly.</p>
</li>
<li>
<p>Use <code>WebAssembly.instantiateStreaming</code> if available (<a
href="https://github-redirect.dependabot.com/evanw/esbuild/pull/1036">#1036</a>,
<a
href="https://github-redirect.dependabot.com/evanw/esbuild/pull/1900">#1900</a>)</p>
<p>Currently the WebAssembly version of esbuild uses <code>fetch</code>
to download <code>esbuild.wasm</code> and then
<code>WebAssembly.instantiate</code> to compile it. There is a newer API
called <code>WebAssembly.instantiateStreaming</code> 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 <code>WebAssembly.instantiateStreaming</code> and falls
back to the original approach if that fails.</p>
<p>The implementation for this builds on a PR by <a
href="https://github.com/lbwa"><code>@lbwa</code></a>.</p>
</li>
<li>
<p>Preserve Webpack comments inside constructor calls (<a
href="https://github-redirect.dependabot.com/evanw/esbuild/issues/2439">#2439</a>)</p>
<p>This improves the use of esbuild as a faster TypeScript-to-JavaScript
frontend for Webpack, which has special <a
href="https://webpack.js.org/api/module-methods/#magic-comments">magic
comments</a> inside <code>new Worker()</code> expressions that affect
Webpack's behavior.</p>
</li>
</ul>
</blockquote>
</details>
<details>
<summary>Changelog</summary>
<p><em>Sourced from <a
href="https://github.com/evanw/esbuild/blob/master/CHANGELOG.md">esbuild's
changelog</a>.</em></p>
<blockquote>
<h2>0.15.18</h2>
<ul>
<li>
<p>Performance improvements for both JS and CSS</p>
<p>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:</p>
<table>
<thead>
<tr>
<th>Test case</th>
<th>Previous release</th>
<th>This release</th>
</tr>
</thead>
<tbody>
<tr>
<td>4.8mb CSS file</td>
<td>19ms</td>
<td>11ms (1.7x faster)</td>
</tr>
<tr>
<td>5.8mb JS file</td>
<td>36ms</td>
<td>32ms (1.1x faster)</td>
</tr>
</tbody>
</table>
<p>The performance improvements were very straightforward:</p>
<ul>
<li>
<p>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.</p>
</li>
<li>
<p>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?</p>
</li>
<li>
<p>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.</p>
</li>
</ul>
<p>I definitely should have caught these performance issues earlier.
Better late than never I suppose.</p>
</li>
</ul>
<h2>0.15.17</h2>
<ul>
<li>
<p>Search for missing source map code on the file system (<a
href="https://github-redirect.dependabot.com/evanw/esbuild/issues/2711">#2711</a>)</p>
<p><a href="https://sourcemaps.info/spec.html">Source maps</a> are JSON
files that map from compiled code back to the original code. They
provide the original source code using two arrays: <code>sources</code>
(required) and <code>sourcesContent</code> (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).</p>
<p>Previously if the input source maps omitted the optional
<code>sourcesContent</code> array, esbuild would use <code>null</code>
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 <code>sources</code> array and will use that instead of
<code>null</code> if it was found.</p>
</li>
<li>
<p>Fix parsing bug with TypeScript <code>infer</code> and
<code>extends</code> (<a
href="https://github-redirect.dependabot.com/evanw/esbuild/issues/2712">#2712</a>)</p>
<p>This release fixes a bug where esbuild incorrectly failed to parse
valid TypeScript code that nests <code>extends</code> inside
<code>infer</code> inside <code>extends</code>, such as in the example
below:</p>
<pre lang="ts"><code>type A<T> = {};
type B = {} extends infer T extends {} ? A<T> : never;
</code></pre>
<p>TypeScript code that does this should now be parsed correctly.</p>
</li>
<li>
<p>Use <code>WebAssembly.instantiateStreaming</code> if available (<a
href="https://github-redirect.dependabot.com/evanw/esbuild/pull/1036">#1036</a>,
<a
href="https://github-redirect.dependabot.com/evanw/esbuild/pull/1900">#1900</a>)</p>
<p>Currently the WebAssembly version of esbuild uses <code>fetch</code>
to download <code>esbuild.wasm</code> and then
<code>WebAssembly.instantiate</code> to compile it. There is a newer API
called <code>WebAssembly.instantiateStreaming</code> 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 <code>WebAssembly.instantiateStreaming</code> and falls
back to the original approach if that fails.</p>
<p>The implementation for this builds on a PR by <a
href="https://github.com/lbwa"><code>@lbwa</code></a>.</p>
</li>
<li>
<p>Preserve Webpack comments inside constructor calls (<a
href="https://github-redirect.dependabot.com/evanw/esbuild/issues/2439">#2439</a>)</p>
<p>This improves the use of esbuild as a faster TypeScript-to-JavaScript
frontend for Webpack, which has special <a
href="https://webpack.js.org/api/module-methods/#magic-comments">magic
comments</a> inside <code>new Worker()</code> expressions that affect
Webpack's behavior.</p>
</li>
</ul>
</blockquote>
</details>
<details>
<summary>Commits</summary>
<ul>
<li><a
href="https://github.com/evanw/esbuild/commit/2953831c60ea7e76dd1372204e23bdf7ff4ea459"><code>2953831</code></a>
publish 0.15.18 to npm</li>
<li><a
href="https://github.com/evanw/esbuild/commit/a3ba2b25d4d1f388ffdd63b07ea105810e4249d7"><code>a3ba2b2</code></a>
perf release notes</li>
<li><a
href="https://github.com/evanw/esbuild/commit/f0d8fdda9b789bd2f9ba9b3002b486249898ceb1"><code>f0d8fdd</code></a>
oops: skip source maps for improved performance</li>
<li><a
href="https://github.com/evanw/esbuild/commit/e49e093ad80178feaf947739ce0d4d411a023544"><code>e49e093</code></a>
css: optimize printing quoted unescaped strings</li>
<li><a
href="https://github.com/evanw/esbuild/commit/a193324e8f5621c30ad6ef61ffae419dfc0e72a1"><code>a193324</code></a>
css: improve identifier printing performance</li>
<li><a
href="https://github.com/evanw/esbuild/commit/83b558034af1bb1f4b8f43639958b12c76e17b6f"><code>83b5580</code></a>
css: pretty-print test failures</li>
<li><a
href="https://github.com/evanw/esbuild/commit/2b8883cae1e4e9b1eb4ec46da1954260db545cf6"><code>2b8883c</code></a>
css: improve lexer identifier parsing performance</li>
<li><a
href="https://github.com/evanw/esbuild/commit/f6f8b27a0d58acff793049873902286e35d0de4b"><code>f6f8b27</code></a>
js: improve lexer identifier parsing performance</li>
<li><a
href="https://github.com/evanw/esbuild/commit/decf208045e3bfa588368bf6be8e7ea02c87a82c"><code>decf208</code></a>
restrict gc disable to not serve or watch mode</li>
<li><a
href="https://github.com/evanw/esbuild/commit/2030df11c79513126481d65a088a4509d09d8082"><code>2030df1</code></a>
don't disable the gc with multiple entry points</li>
<li>Additional commits viewable in <a
href="https://github.com/evanw/esbuild/compare/v0.15.16...v0.15.18">compare
view</a></li>
</ul>
</details>
<br />
[](https://docs.github.com/en/github/managing-security-vulnerabilities/about-dependabot-security-updates#about-compatibility-scores)
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-automerge-start)
[//]: # (dependabot-automerge-end)
---
<details>
<summary>Dependabot commands and options</summary>
<br />
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)
</details>
Signed-off-by: dependabot[bot] <[email protected]>
Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
Co-authored-by: kodiakhq[bot] <49736102+kodiakhq[bot]@users.noreply.github.com>1 parent 8a4e81f commit 541d50a
1 file changed
+184
-184
lines changed
0 commit comments