chore(deps-dev): bump esbuild from 0.15.12 to 0.15.13 (#29)

Bumps [esbuild](https://github.com/evanw/esbuild) from 0.15.12 to 0.15.13.
<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.13</h2>
<ul>
<li>
<p>Add support for the TypeScript 4.9 <code>satisfies</code> operator (<a href="https://github-redirect.dependabot.com/evanw/esbuild/pull/2509">#2509</a>)</p>
<p>TypeScript 4.9 introduces a new operator called <code>satisfies</code> that lets you check that a given value satisfies a less specific type without casting it to that less specific type and without generating any additional code at run-time. It looks like this:</p>
<pre lang="ts"><code>const value = { foo: 1, bar: false } satisfies Record&lt;string, number | boolean&gt;
console.log(value.foo.toFixed(1)) // TypeScript knows that &quot;foo&quot; is a number here
</code></pre>
<p>Before this existed, you could use a cast with <code>as</code> to check that a value satisfies a less specific type, but that removes any additional knowledge that TypeScript has about that specific value:</p>
<pre lang="ts"><code>const value = { foo: 1, bar: false } as Record&lt;string, number | boolean&gt;
console.log(value.foo.toFixed(1)) // TypeScript no longer knows that &quot;foo&quot; is a number
</code></pre>
<p>You can read more about this feature in <a href="https://devblogs.microsoft.com/typescript/announcing-typescript-4-9-rc/#the-satisfies-operator">TypeScript's blog post for 4.9</a> as well as <a href="https://github-redirect.dependabot.com/microsoft/TypeScript/issues/47920">the associated TypeScript issue for this feature</a>.</p>
<p>This feature was implemented in esbuild by <a href="https://github.com/magic-akari"><code>@​magic-akari</code></a>.</p>
</li>
<li>
<p>Fix watch mode constantly rebuilding if the parent directory is inaccessible (<a href="https://github-redirect.dependabot.com/evanw/esbuild/issues/2640">#2640</a>)</p>
<p>Android is unusual in that it has an inaccessible directory in the path to the root, which esbuild was not originally built to handle. To handle cases like this, the path resolution layer in esbuild has a hack where it treats inaccessible directories as empty. However, esbuild's watch implementation currently triggers a rebuild if a directory previously encountered an error but the directory now exists. The assumption is that the previous error was caused by the directory not existing. Although that's usually the case, it's not the case for this particular parent directory on Android. Instead the error is that the directory previously existed but was inaccessible.</p>
<p>This discrepancy between esbuild's path resolution layer and its watch mode was causing watch mode to rebuild continuously on Android. With this release, esbuild's watch mode instead checks for an error status change in the <code>readdir</code> file system call, so watch mode should no longer rebuild continuously on Android.</p>
</li>
<li>
<p>Apply a fix for a rare deadlock with the JavaScript API (<a href="https://github-redirect.dependabot.com/evanw/esbuild/issues/1842">#1842</a>, <a href="https://github-redirect.dependabot.com/evanw/esbuild/issues/2485">#2485</a>)</p>
<p>There have been reports of esbuild sometimes exiting with an &quot;all goroutines are asleep&quot; deadlock message from the Go language runtime. This issue hasn't made much progress until recently, where a possible cause was discovered (thanks to <a href="https://github.com/jfirebaugh"><code>@​jfirebaugh</code></a> for the investigation). This release contains a possible fix for that possible cause, so this deadlock may have been fixed. The fix cannot be easily verified because the deadlock is non-deterministic and rare. If this was indeed the cause, then this issue only affected the JavaScript API in situations where esbuild was already in the process of exiting.</p>
<p>In detail: The underlying cause is that Go's <a href="https://pkg.go.dev/sync#WaitGroup"><code>sync.WaitGroup</code></a> API for waiting for a set of goroutines to finish is not fully thread-safe. Specifically it's not safe to call <code>Add()</code> concurrently with <code>Wait()</code> when the wait group counter is zero due to a data race. This situation could come up with esbuild's JavaScript API when the host JavaScript process closes the child process's stdin and the child process (with no active tasks) calls <code>Wait()</code> to check that there are no active tasks, at the same time as esbuild's watchdog timer calls <code>Add()</code> to add an active task (that pings the host to see if it's still there). The fix in this release is to avoid calling <code>Add()</code> once we learn that stdin has been closed but before we call <code>Wait()</code>.</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.13</h2>
<ul>
<li>
<p>Add support for the TypeScript 4.9 <code>satisfies</code> operator (<a href="https://github-redirect.dependabot.com/evanw/esbuild/pull/2509">#2509</a>)</p>
<p>TypeScript 4.9 introduces a new operator called <code>satisfies</code> that lets you check that a given value satisfies a less specific type without casting it to that less specific type and without generating any additional code at run-time. It looks like this:</p>
<pre lang="ts"><code>const value = { foo: 1, bar: false } satisfies Record&lt;string, number | boolean&gt;
console.log(value.foo.toFixed(1)) // TypeScript knows that &quot;foo&quot; is a number here
</code></pre>
<p>Before this existed, you could use a cast with <code>as</code> to check that a value satisfies a less specific type, but that removes any additional knowledge that TypeScript has about that specific value:</p>
<pre lang="ts"><code>const value = { foo: 1, bar: false } as Record&lt;string, number | boolean&gt;
console.log(value.foo.toFixed(1)) // TypeScript no longer knows that &quot;foo&quot; is a number
</code></pre>
<p>You can read more about this feature in <a href="https://devblogs.microsoft.com/typescript/announcing-typescript-4-9-rc/#the-satisfies-operator">TypeScript's blog post for 4.9</a> as well as <a href="https://github-redirect.dependabot.com/microsoft/TypeScript/issues/47920">the associated TypeScript issue for this feature</a>.</p>
<p>This feature was implemented in esbuild by <a href="https://github.com/magic-akari"><code>@​magic-akari</code></a>.</p>
</li>
<li>
<p>Fix watch mode constantly rebuilding if the parent directory is inaccessible (<a href="https://github-redirect.dependabot.com/evanw/esbuild/issues/2640">#2640</a>)</p>
<p>Android is unusual in that it has an inaccessible directory in the path to the root, which esbuild was not originally built to handle. To handle cases like this, the path resolution layer in esbuild has a hack where it treats inaccessible directories as empty. However, esbuild's watch implementation currently triggers a rebuild if a directory previously encountered an error but the directory now exists. The assumption is that the previous error was caused by the directory not existing. Although that's usually the case, it's not the case for this particular parent directory on Android. Instead the error is that the directory previously existed but was inaccessible.</p>
<p>This discrepancy between esbuild's path resolution layer and its watch mode was causing watch mode to rebuild continuously on Android. With this release, esbuild's watch mode instead checks for an error status change in the <code>readdir</code> file system call, so watch mode should no longer rebuild continuously on Android.</p>
</li>
<li>
<p>Apply a fix for a rare deadlock with the JavaScript API (<a href="https://github-redirect.dependabot.com/evanw/esbuild/issues/1842">#1842</a>, <a href="https://github-redirect.dependabot.com/evanw/esbuild/issues/2485">#2485</a>)</p>
<p>There have been reports of esbuild sometimes exiting with an &quot;all goroutines are asleep&quot; deadlock message from the Go language runtime. This issue hasn't made much progress until recently, where a possible cause was discovered (thanks to <a href="https://github.com/jfirebaugh"><code>@​jfirebaugh</code></a> for the investigation). This release contains a possible fix for that possible cause, so this deadlock may have been fixed. The fix cannot be easily verified because the deadlock is non-deterministic and rare. If this was indeed the cause, then this issue only affected the JavaScript API in situations where esbuild was already in the process of exiting.</p>
<p>In detail: The underlying cause is that Go's <a href="https://pkg.go.dev/sync#WaitGroup"><code>sync.WaitGroup</code></a> API for waiting for a set of goroutines to finish is not fully thread-safe. Specifically it's not safe to call <code>Add()</code> concurrently with <code>Wait()</code> when the wait group counter is zero due to a data race. This situation could come up with esbuild's JavaScript API when the host JavaScript process closes the child process's stdin and the child process (with no active tasks) calls <code>Wait()</code> to check that there are no active tasks, at the same time as esbuild's watchdog timer calls <code>Add()</code> to add an active task (that pings the host to see if it's still there). The fix in this release is to avoid calling <code>Add()</code> once we learn that stdin has been closed but before we call <code>Wait()</code>.</p>
</li>
</ul>
</blockquote>
</details>
<details>
<summary>Commits</summary>
<ul>
<li><a href="https://github.com/evanw/esbuild/commit/ba4771032805f950982ab81cc099783bc6cd90c7"><code>ba47710</code></a> publish 0.15.13 to npm</li>
<li><a href="https://github.com/evanw/esbuild/commit/679548fc2073108b0206231ec74896610d88f880"><code>679548f</code></a> small code simplification</li>
<li><a href="https://github.com/evanw/esbuild/commit/78d61944fb443e2fb987f4fa9c8fc6cf5f790fe1"><code>78d6194</code></a> attempted fix for <a href="https://github-redirect.dependabot.com/evanw/esbuild/issues/2485">#2485</a>: <code>Add</code> and <code>Wait</code> safety</li>
<li><a href="https://github.com/evanw/esbuild/commit/4f9694b2396f4a070f7b5b4348169d8d7789ad79"><code>4f9694b</code></a> fix a typo</li>
<li><a href="https://github.com/evanw/esbuild/commit/8d0c2b9ff5b49d4e012f9d9906235162470e0a9c"><code>8d0c2b9</code></a> update go 1.19.2 =&gt; 1.19.3</li>
<li><a href="https://github.com/evanw/esbuild/commit/8c2fdc2966fb3987394c25398a43494ec650d455"><code>8c2fdc2</code></a> support TypeScript <code>satisfies</code> (<a href="https://github-redirect.dependabot.com/evanw/esbuild/issues/2509">#2509</a>)</li>
<li><a href="https://github.com/evanw/esbuild/commit/97d6dbaff48210589f339dd80c2c372896dadf92"><code>97d6dba</code></a> fix <a href="https://github-redirect.dependabot.com/evanw/esbuild/issues/2640">#2640</a>: watch mode checks <code>readdir</code>, not <code>stat</code></li>
<li>See full diff in <a href="https://github.com/evanw/esbuild/compare/v0.15.12...v0.15.13">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.15.12&new-version=0.15.13)](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>