deps: bump esbuild from 0.21.4 to 0.21.5 in the dependency-updates gr…

…oup (#863)

Bumps the dependency-updates group with 1 update:
[esbuild](https://github.com/evanw/esbuild).

Updates `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 <dependency name> major version` will close this
group update PR and stop Dependabot creating any more for the specific
dependency's major version (unless you unignore this specific
dependency's major version or upgrade to it yourself)
- `@dependabot ignore <dependency name> minor version` will close this
group update PR and stop Dependabot creating any more for the specific
dependency's minor version (unless you unignore this specific
dependency's minor version or upgrade to it yourself)
- `@dependabot ignore <dependency name>` will close this group update PR
and stop Dependabot creating any more for the specific dependency
(unless you unignore this specific dependency or upgrade to it yourself)
- `@dependabot unignore <dependency name>` will remove all of the ignore
conditions of the specified dependency
- `@dependabot unignore <dependency name> <ignore condition>` will
remove the ignore condition of the specified dependency and ignore
conditions


</details>

Signed-off-by: dependabot[bot] <[email protected]>
Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>