chore(deps): update dependency esbuild to ^0.18.13

[cultureamp-renovate]

This PR contains the following updates:

Package	Change	Age	Adoption	Passing	Confidence
esbuild	^0.18.11 -> ^0.18.13

---

Release Notes

evanw/esbuild

v0.18.13

Compare Source

• Add the --drop-labels= option (#​2398)

  If you want to conditionally disable some development-only code and have it not be present in the final production bundle, right now the most straightforward way of doing this is to use the --define: flag along with a specially-named global variable. For example, consider the following code:

  function main() {
    DEV && doAnExpensiveCheck()
  }

  You can build this for development and production like this:

  • Development: esbuild --define:DEV=true
  • Production: esbuild --define:DEV=false

  One drawback of this approach is that the resulting code crashes if you don't provide a value for DEV with --define:. In practice this isn't that big of a problem, and there are also various ways to work around this.

  However, another approach that avoids this drawback is to use JavaScript label statements instead. That's what the --drop-labels= flag implements. For example, consider the following code:

  function main() {
    DEV: doAnExpensiveCheck()
  }

  With this release, you can now build this for development and production like this:

  • Development: esbuild
  • Production: esbuild --drop-labels=DEV

  This means that code containing optional development-only checks can now be written such that it's safe to run without any additional configuration. The --drop-labels= flag takes comma-separated list of multiple label names to drop.

• Avoid causing unhandledRejection during shutdown (#​3219)

  All pending esbuild JavaScript API calls are supposed to fail if esbuild's underlying child process is unexpectedly terminated. This can happen if SIGINT is sent to the parent node process with Ctrl+C, for example. Previously doing this could also cause an unhandled promise rejection when esbuild attempted to communicate this failure to its own child process that no longer exists. This release now swallows this communication failure, which should prevent this internal unhandled promise rejection. This change means that you can now use esbuild's JavaScript API with a custom SIGINT handler that extends the lifetime of the node process without esbuild's internals causing an early exit due to an unhandled promise rejection.

• Update browser compatibility table scripts

  The scripts that esbuild uses to compile its internal browser compatibility table have been overhauled. Briefly:

  • Converted from JavaScript to TypeScript
  • Fixed some bugs that resulted in small changes to the table
  • Added caniuse-lite and @mdn/browser-compat-data as new data sources (replacing manually-copied information)

  This change means it's now much easier to keep esbuild's internal compatibility tables up to date. You can review the table changes here if you need to debug something about this change:

  • JS table changes
  • CSS table changes

v0.18.12

Compare Source

• Fix a panic with const enum inside parentheses (#​3205)

  This release fixes an edge case where esbuild could potentially panic if a TypeScript const enum statement was used inside of a parenthesized expression and was followed by certain other scope-related statements. Here's a minimal example that triggers this edge case:

  (() => {
    const enum E { a };
    () => E.a
  })

• Allow a newline in the middle of TypeScript export type statement (#​3225)

  Previously esbuild incorrectly rejected the following valid TypeScript code:

  export type
  { T };
  
  export type
  * as foo from 'bar';

  Code that uses a newline after export type is now allowed starting with this release.

• Fix cross-module inlining of string enums (#​3210)

  A refactoring typo in version 0.18.9 accidentally introduced a regression with cross-module inlining of string enums when combined with computed property accesses. This regression has been fixed.

• Rewrite .js to .ts inside packages with exports (#​3201)

  Packages with the exports field are supposed to disable node's path resolution behavior that allows you to import a file with a different extension than the one in the source code (for example, importing foo/bar to get foo/bar.js). And TypeScript has behavior where you can import a non-existent .js file and you will get the .ts file instead. Previously the presence of the exports field caused esbuild to disable all extension manipulation stuff which included both node's implicit file extension searching and TypeScript's file extension swapping. However, TypeScript appears to always apply file extension swapping even in this case. So with this release, esbuild will now rewrite .js to .ts even inside packages with exports.

• Fix a redirect edge case in esbuild's development server (#​3208)

  The development server canonicalizes directory URLs by adding a trailing slash. For example, visiting /about redirects to /about/ if /about/index.html would be served. However, if the requested path begins with two slashes, then the redirect incorrectly turned into a protocol-relative URL. For example, visiting //about redirected to //about/ which the browser turns into http://about/. This release fixes the bug by canonicalizing the URL path when doing this redirect.

---

Configuration

📅 Schedule: Branch creation - At any time (no schedule defined), Automerge - At any time (no schedule defined).

🚦 Automerge: Enabled.

♻ Rebasing: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox.

👻 Immortal: This PR will be recreated if closed unmerged. Get config help if that's undesired.

---

• If you want to rebase/retry this PR, check this box

---

This PR has been generated by Renovate Bot.

[cultureamp-renovate]

Branch automerge failure

This PR was configured for branch automerge. However, this is not possible, so it has been raised as a PR instead.

---

• Branch has one or more failed status checks

[changeset-bot]

⚠️ No Changeset found

Latest commit: 578ed8e

Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.

This PR includes no changesets

When changesets are added to this PR, you'll see the packages that this PR includes changesets for and the associated semver types

Click here to learn what changesets are, and how to add one.

Click here if you're a maintainer who wants to add a changeset to this PR