Bump esbuild from 0.21.4 to 0.21.5 (#273)

Bumps [esbuild](https://github.com/evanw/esbuild) from 0.21.4 to 0.21.5.
<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.21.5</h2>
<ul>
<li>
<p>Fix <code>Symbol.metadata</code> on classes without a class decorator
(<a
href="https://redirect.github.com/evanw/esbuild/issues/3781">#3781</a>)</p>
<p>This release fixes a bug with esbuild's support for the <a
href="https://github.com/tc39/proposal-decorator-metadata">decorator
metadata proposal</a>. Previously esbuild only added the
<code>Symbol.metadata</code> property to decorated classes if there was
a decorator on the class element itself. However, the proposal says that
the <code>Symbol.metadata</code> property should be present on all
classes that have any decorators at all, not just those with a decorator
on the class element itself.</p>
</li>
<li>
<p>Allow unknown import attributes to be used with the <code>copy</code>
loader (<a
href="https://redirect.github.com/evanw/esbuild/issues/3792">#3792</a>)</p>
<p>Import attributes (the <code>with</code> keyword on
<code>import</code> statements) are allowed to alter how that path is
loaded. For example, esbuild cannot assume that it knows how to load
<code>./bagel.js</code> as type <code>bagel</code>:</p>
<pre lang="js"><code>// This is an error with &quot;--bundle&quot;
without also using &quot;--external:./bagel.js&quot;
import tasty from &quot;./bagel.js&quot; with { type: &quot;bagel&quot;
}
</code></pre>
<p>Because of that, bundling this code with esbuild is an error unless
the file <code>./bagel.js</code> is external to the bundle (such as with
<code>--bundle --external:./bagel.js</code>).</p>
<p>However, there is an additional case where it's ok for esbuild to
allow this: if the file is loaded using the <code>copy</code> loader.
That's because the <code>copy</code> loader behaves similarly to
<code>--external</code> in that the file is left external to the bundle.
The difference is that the <code>copy</code> loader copies the file into
the output folder and rewrites the import path while
<code>--external</code> doesn't. That means the following will now work
with the <code>copy</code> loader (such as with <code>--bundle
--loader:.bagel=copy</code>):</p>
<pre lang="js"><code>// This is no longer an error with
&quot;--bundle&quot; and &quot;--loader:.bagel=copy&quot;
import tasty from &quot;./tasty.bagel&quot; with { type:
&quot;bagel&quot; }
</code></pre>
</li>
<li>
<p>Support import attributes with glob-style imports (<a
href="https://redirect.github.com/evanw/esbuild/issues/3797">#3797</a>)</p>
<p>This release adds support for import attributes (the
<code>with</code> option) to glob-style imports (dynamic imports with
certain string literal patterns as paths). These imports previously
didn't support import attributes due to an oversight. So code like this
will now work correctly:</p>
<pre lang="ts"><code>async function loadLocale(locale: string): Locale {
const data = await import(`./locales/${locale}.data`, { with: { type:
'json' } })
  return unpackLocale(locale, data)
}
</code></pre>
<p>Previously this didn't work even though esbuild normally supports
forcing the JSON loader using an import attribute. Attempting to do this
used to result in the following error:</p>
<pre><code>✘ [ERROR] No loader is configured for &quot;.data&quot;
files: locales/en-US.data
<pre><code>example.ts:2:28:
2 │ const data = await import(`./locales/${locale}.data`, { with: {
type: 'json' } })
    ╵                             ~~~~~~~~~~~~~~~~~~~~~~~~~~
</code></pre>
<p></code></pre></p>
<p>In addition, this change means plugins can now access the contents of
<code>with</code> for glob-style imports.</p>
</li>
<li>
<p>Support <code>${configDir}</code> in <code>tsconfig.json</code> files
(<a
href="https://redirect.github.com/evanw/esbuild/issues/3782">#3782</a>)</p>
<p>This adds support for a new feature from the upcoming TypeScript 5.5
release. The character sequence <code>${configDir}</code> is now
respected at the start of <code>baseUrl</code> and <code>paths</code>
values, which are used by esbuild during bundling to correctly map
import paths to file system paths. This feature lets base
<code>tsconfig.json</code> files specified via <code>extends</code>
refer to the directory of the top-level <code>tsconfig.json</code> file.
Here is an example:</p>
</li>
</ul>
<!-- raw HTML omitted -->
</blockquote>
<p>... (truncated)</p>
</details>
<details>
<summary>Changelog</summary>
<p><em>Sourced from <a
href="https://github.com/evanw/esbuild/blob/main/CHANGELOG.md">esbuild's
changelog</a>.</em></p>
<blockquote>
<h2>0.21.5</h2>
<ul>
<li>
<p>Fix <code>Symbol.metadata</code> on classes without a class decorator
(<a
href="https://redirect.github.com/evanw/esbuild/issues/3781">#3781</a>)</p>
<p>This release fixes a bug with esbuild's support for the <a
href="https://github.com/tc39/proposal-decorator-metadata">decorator
metadata proposal</a>. Previously esbuild only added the
<code>Symbol.metadata</code> property to decorated classes if there was
a decorator on the class element itself. However, the proposal says that
the <code>Symbol.metadata</code> property should be present on all
classes that have any decorators at all, not just those with a decorator
on the class element itself.</p>
</li>
<li>
<p>Allow unknown import attributes to be used with the <code>copy</code>
loader (<a
href="https://redirect.github.com/evanw/esbuild/issues/3792">#3792</a>)</p>
<p>Import attributes (the <code>with</code> keyword on
<code>import</code> statements) are allowed to alter how that path is
loaded. For example, esbuild cannot assume that it knows how to load
<code>./bagel.js</code> as type <code>bagel</code>:</p>
<pre lang="js"><code>// This is an error with &quot;--bundle&quot;
without also using &quot;--external:./bagel.js&quot;
import tasty from &quot;./bagel.js&quot; with { type: &quot;bagel&quot;
}
</code></pre>
<p>Because of that, bundling this code with esbuild is an error unless
the file <code>./bagel.js</code> is external to the bundle (such as with
<code>--bundle --external:./bagel.js</code>).</p>
<p>However, there is an additional case where it's ok for esbuild to
allow this: if the file is loaded using the <code>copy</code> loader.
That's because the <code>copy</code> loader behaves similarly to
<code>--external</code> in that the file is left external to the bundle.
The difference is that the <code>copy</code> loader copies the file into
the output folder and rewrites the import path while
<code>--external</code> doesn't. That means the following will now work
with the <code>copy</code> loader (such as with <code>--bundle
--loader:.bagel=copy</code>):</p>
<pre lang="js"><code>// This is no longer an error with
&quot;--bundle&quot; and &quot;--loader:.bagel=copy&quot;
import tasty from &quot;./tasty.bagel&quot; with { type:
&quot;bagel&quot; }
</code></pre>
</li>
<li>
<p>Support import attributes with glob-style imports (<a
href="https://redirect.github.com/evanw/esbuild/issues/3797">#3797</a>)</p>
<p>This release adds support for import attributes (the
<code>with</code> option) to glob-style imports (dynamic imports with
certain string literal patterns as paths). These imports previously
didn't support import attributes due to an oversight. So code like this
will now work correctly:</p>
<pre lang="ts"><code>async function loadLocale(locale: string): Locale {
const data = await import(`./locales/${locale}.data`, { with: { type:
'json' } })
  return unpackLocale(locale, data)
}
</code></pre>
<p>Previously this didn't work even though esbuild normally supports
forcing the JSON loader using an import attribute. Attempting to do this
used to result in the following error:</p>
<pre><code>✘ [ERROR] No loader is configured for &quot;.data&quot;
files: locales/en-US.data
<pre><code>example.ts:2:28:
2 │ const data = await import(`./locales/${locale}.data`, { with: {
type: 'json' } })
    ╵                             ~~~~~~~~~~~~~~~~~~~~~~~~~~
</code></pre>
<p></code></pre></p>
<p>In addition, this change means plugins can now access the contents of
<code>with</code> for glob-style imports.</p>
</li>
<li>
<p>Support <code>${configDir}</code> in <code>tsconfig.json</code> files
(<a
href="https://redirect.github.com/evanw/esbuild/issues/3782">#3782</a>)</p>
<p>This adds support for a new feature from the upcoming TypeScript 5.5
release. The character sequence <code>${configDir}</code> is now
respected at the start of <code>baseUrl</code> and <code>paths</code>
values, which are used by esbuild during bundling to correctly map
import paths to file system paths. This feature lets base
<code>tsconfig.json</code> files specified via <code>extends</code>
refer to the directory of the top-level <code>tsconfig.json</code> file.
Here is an example:</p>
</li>
</ul>
<!-- raw HTML omitted -->
</blockquote>
<p>... (truncated)</p>
</details>
<details>
<summary>Commits</summary>
<ul>
<li><a
href="https://github.com/evanw/esbuild/commit/fc37c2fa9de2ad77476a6d4a8f1516196b90187e"><code>fc37c2f</code></a>
publish 0.21.5 to npm</li>
<li><a
href="https://github.com/evanw/esbuild/commit/cb119249a19603b12fdf8df1c5a81c21420a1cb0"><code>cb11924</code></a>
fix <code>Symbol.metadata</code> errors in decorator tests</li>
<li><a
href="https://github.com/evanw/esbuild/commit/b93a2a95ac697f4aa01471e0a383a25626f1998e"><code>b93a2a9</code></a>
fix <a
href="https://redirect.github.com/evanw/esbuild/issues/3781">#3781</a>:
add metadata to all decorated classes</li>
<li><a
href="https://github.com/evanw/esbuild/commit/953dae945b265df7d9728dbd961f7a27dce941cd"><code>953dae9</code></a>
fix <a
href="https://redirect.github.com/evanw/esbuild/issues/3797">#3797</a>:
import attributes and glob-style import</li>
<li><a
href="https://github.com/evanw/esbuild/commit/98cb2ed72cfc4187f45fe1a6abe5417ad613356b"><code>98cb2ed</code></a>
fix <a
href="https://redirect.github.com/evanw/esbuild/issues/3782">#3782</a>:
support <code>${configDir}</code> in tsconfig.json</li>
<li><a
href="https://github.com/evanw/esbuild/commit/8e6603b83f6be8de8204a7c5af755874f8b8da68"><code>8e6603b</code></a>
run <code>make update-compat-table</code></li>
<li><a
href="https://github.com/evanw/esbuild/commit/db1b8ca20f26091fbaebd5b4a8ce950de984e750"><code>db1b8ca</code></a>
fix <a
href="https://redirect.github.com/evanw/esbuild/issues/3792">#3792</a>:
import attributes and the <code>copy</code> loader</li>
<li><a
href="https://github.com/evanw/esbuild/commit/de572d0e5363fef5457d3581ec340e481b139152"><code>de572d0</code></a>
fix non-deterministic import attribute plugin test</li>
<li><a
href="https://github.com/evanw/esbuild/commit/ae8d1b4f307b290bde0f17aceb51dd6f62eac64c"><code>ae8d1b4</code></a>
fix <a
href="https://redirect.github.com/evanw/esbuild/issues/3794">#3794</a>:
<code>--supported:object-accessors=false</code></li>
<li>See full diff in <a
href="https://github.com/evanw/esbuild/compare/v0.21.4...v0.21.5">compare
view</a></li>
</ul>
</details>
<br />


[![Dependabot compatibility
score](https://dependabot-badges.githubapp.com/badges/compatibility_score?dependency-name=esbuild&package-manager=npm_and_yarn&previous-version=0.21.4&new-version=0.21.5)](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 show <dependency name> ignore conditions` will show all
of the ignore conditions of the specified dependency
- `@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] <support@github.com>
Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>