chore(deps): update dependency esbuild to v0.28.0 (#9022)

> ℹ️ **Note**
> 
> This PR body was truncated due to platform limits.

This PR contains the following updates:

| Package | Change |
[Age](https://docs.renovatebot.com/merge-confidence/) |
[Confidence](https://docs.renovatebot.com/merge-confidence/) |
|---|---|---|---|
| [esbuild](https://redirect.github.com/evanw/esbuild) | [`0.21.5` →
`0.28.0`](https://renovatebot.com/diffs/npm/esbuild/0.21.5/0.28.0) |
![age](https://developer.mend.io/api/mc/badges/age/npm/esbuild/0.28.0?slim=true)
|
![confidence](https://developer.mend.io/api/mc/badges/confidence/npm/esbuild/0.21.5/0.28.0?slim=true)
|

---

### Release Notes

<details>
<summary>evanw/esbuild (esbuild)</summary>

###
[`v0.28.0`](https://redirect.github.com/evanw/esbuild/blob/HEAD/CHANGELOG.md#0280)

[Compare
Source](https://redirect.github.com/evanw/esbuild/compare/v0.27.7...v0.28.0)

- Add support for `with { type: 'text' }` imports
([#&#8203;4435](https://redirect.github.com/evanw/esbuild/issues/4435))

The [import text](https://redirect.github.com/tc39/proposal-import-text)
proposal has reached stage 3 in the TC39 process, which means that it's
recommended for implementation. It has also already been implemented by
[Deno](https://docs.deno.com/examples/importing_text/) and
[Bun](https://bun.com/docs/guides/runtime/import-html). So with this
release, esbuild also adds support for it. This behaves exactly the same
as esbuild's existing [`text`
loader](https://esbuild.github.io/content-types/#text). Here's an
example:

  ```js
  import string from './example.txt' with { type: 'text' }
  console.log(string)
  ```

- Add integrity checks to fallback download path
([#&#8203;4343](https://redirect.github.com/evanw/esbuild/issues/4343))

Installing esbuild via npm is somewhat complicated with several
different edge cases (see [esbuild's
documentation](https://esbuild.github.io/getting-started/#additional-npm-flags)
for details). If the regular installation of esbuild's platform-specific
package fails, esbuild's install script attempts to download the
platform-specific package itself (first with the `npm` command, and then
with a HTTP request to `registry.npmjs.org` as a last resort).

This last resort path previously didn't have any integrity checks. With
this release, esbuild will now verify that the hash of the downloaded
binary matches the expected hash for the current release. This means the
hashes for all of esbuild's platform-specific binary packages will now
be embedded in the top-level `esbuild` package. Hopefully this should
work without any problems. But just in case, this change is being done
as a breaking change release.

- Update the Go compiler from 1.25.7 to 1.26.1

This upgrade should not affect anything. However, there have been some
significant internal changes to the Go compiler, so esbuild could
potentially behave differently in certain edge cases:

- It now uses the [new garbage
collector](https://go.dev/doc/go1.26#new-garbage-collector) that comes
with Go 1.26.
- The Go compiler is now more aggressive with allocating memory on the
stack.
- The executable format that the Go linker uses has undergone several
changes.
- The WebAssembly build now unconditionally makes use of the sign
extension and non-trapping floating-point to integer conversion
instructions.

You can read the [Go 1.26 release notes](https://go.dev/doc/go1.26) for
more information.

###
[`v0.27.7`](https://redirect.github.com/evanw/esbuild/blob/HEAD/CHANGELOG.md#0277)

[Compare
Source](https://redirect.github.com/evanw/esbuild/compare/v0.27.5...v0.27.7)

- Fix lowering of define semantics for TypeScript parameter properties
([#&#8203;4421](https://redirect.github.com/evanw/esbuild/issues/4421))

The previous release incorrectly generated class fields for TypeScript
parameter properties even when the configured target environment does
not support class fields. With this release, the generated class fields
will now be correctly lowered in this case:

  ```ts
  // Original code
  class Foo {
    constructor(public x = 1) {}
    y = 2
  }

  // Old output (with --loader=ts --target=es2021)
  class Foo {
    constructor(x = 1) {
      this.x = x;
      __publicField(this, "y", 2);
    }
    x;
  }

  // New output (with --loader=ts --target=es2021)
  class Foo {
    constructor(x = 1) {
      __publicField(this, "x", x);
      __publicField(this, "y", 2);
    }
  }
  ```

###
[`v0.27.5`](https://redirect.github.com/evanw/esbuild/blob/HEAD/CHANGELOG.md#0275)

[Compare
Source](https://redirect.github.com/evanw/esbuild/compare/v0.27.4...v0.27.5)

- Fix for an async generator edge case
([#&#8203;4401](https://redirect.github.com/evanw/esbuild/issues/4401),
[#&#8203;4417](https://redirect.github.com/evanw/esbuild/pull/4417))

Support for transforming async generators into the equivalent state
machine was added in version 0.19.0. However, the generated state
machine didn't work correctly when polling async generators
concurrently, such as in the following code:

  ```js
  async function* inner() { yield 1; yield 2 }
  async function* outer() { yield* inner() }
  let gen = outer()
  for await (let x of [gen.next(), gen.next()]) console.log(x)
  ```

Previously esbuild's output of the above code behaved incorrectly when
async generators were transformed (such as with
`--supported:async-generator=false`). The transformation should be fixed
starting with this release.

This fix was contributed by
[@&#8203;2767mr](https://redirect.github.com/2767mr).

- Fix a regression when `metafile` is enabled
([#&#8203;4420](https://redirect.github.com/evanw/esbuild/issues/4420),
[#&#8203;4418](https://redirect.github.com/evanw/esbuild/pull/4418))

This release fixes a regression introduced by the previous release. When
`metafile: true` was enabled in esbuild's JavaScript API, builds with
build errors were incorrectly throwing an error about an empty JSON
string instead of an object containing the build errors.

- Use define semantics for TypeScript parameter properties
([#&#8203;4421](https://redirect.github.com/evanw/esbuild/issues/4421))

Parameter properties are a TypeScript-specific code generation feature
that converts constructor parameters into class fields when they are
prefixed by certain keywords. When `"useDefineForClassFields": true` is
present in `tsconfig.json`, the TypeScript compiler automatically
generates class field declarations for parameter properties. Previously
esbuild didn't do this, but esbuild will now do this starting with this
release:

  ```ts
  // Original code
  class Foo {
    constructor(public x: number) {}
  }

  // Old output (with --loader=ts)
  class Foo {
    constructor(x) {
      this.x = x;
    }
  }

  // New output (with --loader=ts)
  class Foo {
    constructor(x) {
      this.x = x;
    }
    x;
  }
  ```

- Allow `es2025` as a target in `tsconfig.json`
([#&#8203;4432](https://redirect.github.com/evanw/esbuild/issues/4432))

TypeScript recently [added
`es2025`](https://devblogs.microsoft.com/typescript/announcing-typescript-6-0/#es2025-option-for-target-and-lib)
as a compilation target, so esbuild now supports this in the `target`
field of `tsconfig.json` files, such as in the following configuration
file:

  ```json
  {
    "compilerOptions": {
      "target": "ES2025"
    }
  }
  ```

As a reminder, the only thing that esbuild uses this field for is
determining whether or not to use legacy TypeScript behavior for class
fields. You can read more in [the
documentation](https://esbuild.github.io/content-types/#tsconfig-json).

###
[`v0.27.4`](https://redirect.github.com/evanw/esbuild/blob/HEAD/CHANGELOG.md#0274)

[Compare
Source](https://redirect.github.com/evanw/esbuild/compare/v0.27.3...v0.27.4)

- Fix a regression with CSS media queries
([#&#8203;4395](https://redirect.github.com/evanw/esbuild/issues/4395),
[#&#8203;4405](https://redirect.github.com/evanw/esbuild/issues/4405),
[#&#8203;4406](https://redirect.github.com/evanw/esbuild/issues/4406))

Version 0.25.11 of esbuild introduced support for parsing media queries.
This unintentionally introduced a regression with printing media queries
that use the `<media-type> and <media-condition-without-or>` grammar.
Specifically, esbuild was failing to wrap an `or` clause with
parentheses when inside `<media-condition-without-or>`. This release
fixes the regression.

  Here is an example:

  ```css
  /* Original code */
@&#8203;media only screen and ((min-width: 10px) or (min-height: 10px))
{
    a { color: red }
  }

  /* Old output (incorrect) */
@&#8203;media only screen and (min-width: 10px) or (min-height: 10px) {
    a {
      color: red;
    }
  }

  /* New output (correct) */
@&#8203;media only screen and ((min-width: 10px) or (min-height: 10px))
{
    a {
      color: red;
    }
  }
  ```

- Fix an edge case with the `inject` feature
([#&#8203;4407](https://redirect.github.com/evanw/esbuild/issues/4407))

This release fixes an edge case where esbuild's `inject` feature could
not be used with arbitrary module namespace names exported using an
`export {} from` statement with bundling disabled and a target
environment where arbitrary module namespace names is unsupported.

  With the fix, the following `inject` file:

  ```js
  import jquery from 'jquery';
  export { jquery as 'window.jQuery' };
  ```

Can now always be rewritten as this without esbuild sometimes
incorrectly generating an error:

  ```js
  export { default as 'window.jQuery' } from 'jquery';
  ```

- Attempt to improve API handling of huge metafiles
([#&#8203;4329](https://redirect.github.com/evanw/esbuild/issues/4329),
[#&#8203;4415](https://redirect.github.com/evanw/esbuild/issues/4415))

This release contains a few changes that attempt to improve the behavior
of esbuild's JavaScript API with huge metafiles (esbuild's name for the
build metadata, formatted as a JSON object). The JavaScript API is
designed to return the metafile JSON as a JavaScript object in memory,
which makes it easy to access from within a JavaScript-based plugin.
Multiple people have encountered issues where this API breaks down with
a pathologically-large metafile.

The primary issue is that V8 has an implementation-specific maximum
string length, so using the `JSON.parse` API with large enough strings
is impossible. This release will now attempt to use a fallback
JavaScript-based JSON parser that operates directly on the UTF8-encoded
JSON bytes instead of using `JSON.parse` when the JSON metafile is too
big to fit in a JavaScript string. The new fallback path has not yet
been heavily-tested. The metafile will also now be generated with
whitespace removed if the bundle is significantly large, which will
reduce the size of the metafile JSON slightly.

However, hitting this case is potentially a sign that something else is
wrong. Ideally you wouldn't be building something so enormous that the
build metadata can't even fit inside a JavaScript string. You may want
to consider optimizing your project, or breaking up your project into
multiple parts that are built independently. Another option could
potentially be to use esbuild's command-line API instead of its
JavaScript API, which is more efficient (although of course then you
can't use JavaScript plugins, so it may not be an option).

###
[`v0.27.3`](https://redirect.github.com/evanw/esbuild/blob/HEAD/CHANGELOG.md#0273)

[Compare
Source](https://redirect.github.com/evanw/esbuild/compare/v0.27.2...v0.27.3)

- Preserve URL fragments in data URLs
([#&#8203;4370](https://redirect.github.com/evanw/esbuild/issues/4370))

  Consider the following HTML, CSS, and SVG:

  - `index.html`:

    ```html
    <!DOCTYPE html>
    <html>
      <head><link rel="stylesheet" href="icons.css"></head>
      <body><div class="triangle"></div></body>
    </html>
    ```

  - `icons.css`:

    ```css
    .triangle {
      width: 10px;
      height: 10px;
      background: currentColor;
      clip-path: url(./triangle.svg#x);
    }
    ```

  - `triangle.svg`:

    ```xml
    <svg xmlns="http://www.w3.org/2000/svg">
      <defs>
        <clipPath id="x">
          <path d="M0 0H10V10Z"/>
        </clipPath>
      </defs>
    </svg>
    ```

The CSS uses a URL fragment (the `#x`) to reference the `clipPath`
element in the SVG file. Previously esbuild's CSS bundler didn't
preserve the URL fragment when bundling the SVG using the `dataurl`
loader, which broke the bundled CSS. With this release, esbuild will now
preserve the URL fragment in the bundled CSS:

  ```css
  /* icons.css */
  .triangle {
    width: 10px;
    height: 10px;
    background: currentColor;
clip-path: url('data:image/svg+xml,<svg
xmlns="http://www.w3.org/2000/svg"><defs><clipPath id="x"><path d="M0
0H10V10Z"/></clipPath></defs></svg>#x');
  }
  ```

- Parse and print CSS `@scope` rules
([#&#8203;4322](https://redirect.github.com/evanw/esbuild/issues/4322))

This release includes dedicated support for parsing `@scope` rules in
CSS. These rules include optional "start" and "end" selector lists. One
important consequence of this is that the local/global status of names
in selector lists is now respected, which improves the correctness of
esbuild's support for [CSS
modules](https://esbuild.github.io/content-types/#local-css).
Minification of selectors inside `@scope` rules has also improved
slightly.

  Here's an example:

  ```css
  /* Original code */
  @&#8203;scope (:global(.foo)) to (:local(.bar)) {
    .bar {
      color: red;
    }
  }

  /* Old output (with --loader=local-css --minify) */
  @&#8203;scope (:global(.foo)) to (:local(.bar)){.o{color:red}}

  /* New output (with --loader=local-css --minify) */
  @&#8203;scope(.foo)to (.o){.o{color:red}}
  ```

- Fix a minification bug with lowering of `for await`
([#&#8203;4378](https://redirect.github.com/evanw/esbuild/pull/4378),
[#&#8203;4385](https://redirect.github.com/evanw/esbuild/pull/4385))

This release fixes a bug where the minifier would incorrectly strip the
variable in the automatically-generated `catch` clause of lowered `for
await` loops. The code that generated the loop previously failed to mark
the internal variable references as used.

- Update the Go compiler from v1.25.5 to v1.25.7
([#&#8203;4383](https://redirect.github.com/evanw/esbuild/issues/4383),
[#&#8203;4388](https://redirect.github.com/evanw/esbuild/pull/4388))

This PR was contributed by
[@&#8203;MikeWillCook](https://redirect.github.com/MikeWillCook).

###
[`v0.27.2`](https://redirect.github.com/evanw/esbuild/blob/HEAD/CHANGELOG.md#0272)

[Compare
Source](https://redirect.github.com/evanw/esbuild/compare/v0.27.1...v0.27.2)

- Allow import path specifiers starting with `#/`
([#&#8203;4361](https://redirect.github.com/evanw/esbuild/pull/4361))

Previously the specification for `package.json` disallowed import path
specifiers starting with `#/`, but this restriction [has recently been
relaxed](https://redirect.github.com/nodejs/node/pull/60864) and support
for it is being added across the JavaScript ecosystem. One use case is
using it for a wildcard pattern such as mapping `#/*` to `./src/*`
(previously you had to use another character such as `#_*` instead,
which was more confusing). There is some more context in
[nodejs/node#49182](https://redirect.github.com/nodejs/node/issues/49182).

This change was contributed by
[@&#8203;hybrist](https://redirect.github.com/hybrist).

- Automatically add the `-webkit-mask` prefix
([#&#8203;4357](https://redirect.github.com/evanw/esbuild/issues/4357),
[#&#8203;4358](https://redirect.github.com/evanw/esbuild/issues/4358))

This release automatically adds the `-webkit-` vendor prefix for the
[`mask`](https://developer.mozilla.org/en-US/docs/Web/CSS/Reference/Properties/mask)
CSS shorthand property:

  ```css
  /* Original code */
  main {
    mask: url(x.png) center/5rem no-repeat
  }

  /* Old output (with --target=chrome110) */
  main {
    mask: url(x.png) center/5rem no-repeat;
  }

  /* New output (with --target=chrome110) */
  main {
    -webkit-mask: url(x.png) center/5rem no-repeat;
    mask: url(x.png) center/5rem no-repeat;
  }
  ```

This change was contributed by
[@&#8203;BPJEnnova](https://redirect.github.com/BPJEnnova).

- Additional minification of `switch` statements
([#&#8203;4176](https://redirect.github.com/evanw/esbuild/issues/4176),
[#&#8203;4359](https://redirect.github.com/evanw/esbuild/issues/4359))

This release contains additional minification patterns for reducing
`switch` statements. Here is an example:

  ```js
  // Original code
  switch (x) {
    case 0:
      foo()
      break
    case 1:
    default:
      bar()
  }

  // Old output (with --minify)
  switch(x){case 0:foo();break;case 1:default:bar()}

  // New output (with --minify)
  x===0?foo():bar();
  ```

- Forbid `using` declarations inside `switch` clauses
([#&#8203;4323](https://redirect.github.com/evanw/esbuild/issues/4323))

This is a rare change to remove something that was previously possible.
The [Explicit Resource
Management](https://redirect.github.com/tc39/proposal-explicit-resource-management)
proposal introduced `using` declarations. These were previously allowed
inside `case` and `default` clauses in `switch` statements. This had
well-defined semantics and was already widely implemented (by V8,
SpiderMonkey, TypeScript, esbuild, and others). However, it was
considered to be too confusing because of how scope works in switch
statements, so it has been removed from the specification. This edge
case will now be a syntax error. See
[tc39/proposal-explicit-resource-management#215](https://redirect.github.com/tc39/proposal-explicit-resource-management/issues/215)
and
[rbuckton/ecma262#14](https://redirect.github.com/rbuckton/ecma262/pull/14)
for details.

  Here is an example of code that is no longer allowed:

  ```js
  switch (mode) {
    case 'read':
      using readLock = db.read()
      return readAll(readLock)

    case 'write':
      using writeLock = db.write()
      return writeAll(writeLock)
  }
  ```

That code will now have to be modified to look like this instead (note
the additional `{` and `}` block statements around each case body):

  ```js
  switch (mode) {
    case 'read': {
      using readLock = db.read()
      return readAll(readLock)
    }
    case 'write': {
      using writeLock = db.write()
      return writeAll(writeLock)
    }
  }
  ```

This is not being released in one of esbuild's breaking change releases
since this feature hasn't been finalized yet, and esbuild always tracks
the current state of the specification (so esbuild's previous behavior
was arguably incorrect).

###
[`v0.27.1`](https://redirect.github.com/evanw/esbuild/blob/HEAD/CHANGELOG.md#0271)

[Compare
Source](https://redirect.github.com/evanw/esbuild/compare/v0.27.0...v0.27.1)

- Fix bundler bug with `var` nested inside `if`
([#&#8203;4348](https://redirect.github.com/evanw/esbuild/issues/4348))

This release fixes a bug with the bundler that happens when importing an
ES module using `require` (which causes it to be wrapped) and there's a
top-level `var` inside an `if` statement without being wrapped in a `{
... }` block (and a few other conditions). The bundling transform needed
to hoist these `var` declarations outside of the lazy ES module wrapper
for correctness. See the issue for details.

- Fix minifier bug with `for` inside `try` inside label
([#&#8203;4351](https://redirect.github.com/evanw/esbuild/issues/4351))

This fixes an old regression from [version
v0.21.4](https://redirect.github.com/evanw/esbuild/releases/v0.21.4).
Some code was introduced to move the label inside the `try` statement to
address a problem with transforming labeled `for await` loops to avoid
the `await` (the transformation involves converting the `for await` loop
into a `for` loop and wrapping it in a `try` statement). However, it
introduces problems for cross-compiled JVM code that uses all three of
these features heavily. This release restricts this transform to only
apply to `for` loops that esbuild itself generates internally as part of
the `for await` transform. Here is an example of some affected code:

  ```js
  // Original code
  d: {
    e: {
      try {
        while (1) { break d }
      } catch { break e; }
    }
  }

  // Old output (with --minify)
  a:try{e:for(;;)break a}catch{break e}

  // New output (with --minify)
  a:e:try{for(;;)break a}catch{break e}
  ```

- Inline IIFEs containing a single expression
([#&#8203;4354](https://redirect.github.com/evanw/esbuild/issues/4354))

Previously inlining of IIFEs (immediately-invoked function expressions)
only worked if the body contained a single `return` statement. Now it
should also work if the body contains a single expression statement
instead:

  ```js
  // Original code
  const foo = () => {
    const cb = () => {
      console.log(x())
    }
    return cb()
  }

  // Old output (with --minify)
  const foo=()=>(()=>{console.log(x())})();

  // New output (with --minify)
  const foo=()=>{console.log(x())};
  ```

- The minifier now strips empty `finally` clauses
([#&#8203;4353](https://redirect.github.com/evanw/esbuild/issues/4353))

This improvement means that `finally` clauses containing dead code can
potentially cause the associated `try` statement to be removed from the
output entirely in minified builds:

  ```js
  // Original code
  function foo(callback) {
    if (DEBUG) stack.push(callback.name);
    try {
      callback();
    } finally {
      if (DEBUG) stack.pop();
    }
  }

  // Old output (with --minify --define:DEBUG=false)
  function foo(a){try{a()}finally{}}

  // New output (with --minify --define:DEBUG=false)
  function foo(a){a()}
  ```

- Allow tree-shaking of the `Symbol` constructor

With this release, calling `Symbol` is now considered to be side-effect
free when the argument is known to be a primitive value. This means
esbuild can now tree-shake module-level symbol variables:

  ```js
  // Original code
  const a = Symbol('foo')
  const b = Symbol(bar)

  // Old output (with --tree-shaking=true)
  const a = Symbol("foo");
  const b = Symbol(bar);

  // New output (with --tree-shaking=true)
  const b = Symbol(bar);
  ```

###
[`v0.27.0`](https://redirect.github.com/evanw/esbuild/blob/HEAD/CHANGELOG.md#0270)

[Compare
Source](https://redirect.github.com/evanw/esbuild/compare/v0.26.0...v0.27.0)

**This release deliberately contains backwards-incompatible changes.**
To avoid automatically picking up releases like this, you should either
be pinning the exact version of `esbuild` in your `package.json` file
(recommended) or be using a version range syntax that only accepts patch
upgrades such as `^0.26.0` or `~0.26.0`. See npm's documentation about
[semver](https://docs.npmjs.com/cli/v6/using-npm/semver/) for more
information.

- Use `Uint8Array.fromBase64` if available
([#&#8203;4286](https://redirect.github.com/evanw/esbuild/issues/4286))

With this release, esbuild's `binary` loader will now use the new
[`Uint8Array.fromBase64`](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Uint8Array/fromBase64)
function unless it's unavailable in the configured target environment.
If it's unavailable, esbuild's previous code for this will be used as a
fallback. Note that this means you may now need to specify `target` when
using this feature with Node (for example `--target=node22`) unless
you're using Node v25+.

- Update the Go compiler from v1.23.12 to v1.25.4
([#&#8203;4208](https://redirect.github.com/evanw/esbuild/issues/4208),
[#&#8203;4311](https://redirect.github.com/evanw/esbuild/pull/4311))

  This raises the operating system requirements for running esbuild:

  - Linux: now requires a kernel version of 3.2 or later
  - macOS: now requires macOS 12 (Monterey) or later

###
[`v0.26.0`](https://redirect.github.com/evanw/esbuild/blob/HEAD/CHANGELOG.md#0260)

[Compare
Source](https://redirect.github.com/evanw/esbuild/compare/v0.25.12...v0.26.0)

- Enable trusted publishing
([#&#8203;4281](https://redirect.github.com/evanw/esbuild/issues/4281))

GitHub and npm are recommending that maintainers for packages such as
esbuild switch to [trusted
publishing](https://docs.npmjs.com/trusted-publishers). With this
release, a VM on GitHub will now build and publish all of esbuild's
packages to npm instead of me. In theory.

Unfortunately there isn't really a way to test that this works other
than to do it live. So this release is that live test. Hopefully this
release is uneventful and is exactly the same as the previous one (well,
except for the green provenance attestation checkmark on npm that
happens with trusted publishing).

###
[`v0.25.12`](https://redirect.github.com/evanw/esbuild/blob/HEAD/CHANGELOG.md#02512)

[Compare
Source](https://redirect.github.com/evanw/esbuild/compare/v0.25.11...v0.25.12)

- Fix a minification regression with CSS media queries
([#&#8203;4315](https://redirect.github.com/evanw/esbuild/issues/4315))

The previous release introduced support for parsing media queries which
unintentionally introduced a regression with the removal of duplicate
media rules during minification. Specifically the grammar for `@media
<media-type> and <media-condition-without-or> { ... }` was missing an
equality check for the `<media-condition-without-or>` part, so rules
with different suffix clauses in this position would incorrectly compare
equal and be deduplicated. This release fixes the regression.

- Update the list of known JavaScript globals
([#&#8203;4310](https://redirect.github.com/evanw/esbuild/issues/4310))

This release updates esbuild's internal list of known JavaScript
globals. These are globals that are known to not have side-effects when
the property is accessed. For example, accessing the global `Array`
property is considered to be side-effect free but accessing the global
`scrollY` property can trigger a layout, which is a side-effect. This is
used by esbuild's tree-shaking to safely remove unused code that is
known to be side-effect free. This update adds the following global
properties:

  From [ES2017](https://tc39.es/ecma262/2017/):

  - `Atomics`
  - `SharedArrayBuffer`

  From [ES2020](https://tc39.es/ecma262/2020/):

  - `BigInt64Array`
  - `BigUint64Array`

  From [ES2021](https://tc39.es/ecma262/2021/):

  - `FinalizationRegistry`
  - `WeakRef`

  From [ES2025](https://tc39.es/ecma262/2025/):

  - `Float16Array`
  - `Iterator`

Note that this does not indicate that constructing any of these objects
is side-effect free, just that accessing the identifier is side-effect
free. For example, this now allows esbuild to tree-shake classes that
extend from `Iterator`:

  ```js
  // This can now be tree-shaken by esbuild:
  class ExampleIterator extends Iterator {}
  ```

- Add support for the new `@view-transition` CSS rule
([#&#8203;4313](https://redirect.github.com/evanw/esbuild/pull/4313))

With this release, esbuild now has improved support for pretty-printing
and minifying the new `@view-transition` rule (which esbuild was
previously unaware of):

  ```css
  /* Original code */
  @&#8203;view-transition {
    navigation: auto;
    types: check;
  }

  /* Old output */
  @&#8203;view-transition { navigation: auto; types: check; }

  /* New output */
  @&#8203;view-transition {
    navigation: auto;
    types: check;
  }
  ```

The new view transition feature provides a mechanism for creating
animated transitions between documents in a multi-page app. You can read
more about view transition rules
[here](https://developer.mozilla.org/en-US/docs/Web/CSS/@&#8203;view-transition).

This change was contributed by
[@&#8203;yisibl](https://redirect.github.com/yisibl).

- Trim CSS rules that will never match

The CSS minifier will now remove rules whose selectors contain `:is()`
and `:where()` as those selectors will never match. These selectors can
currently be automatically generated by esbuild when you give esbuild
nonsensical input such as the following:

  ```css
  /* Original code */
  div:before {
    color: green;
    &.foo {
      color: red;
    }
  }

  /* Old output (with --supported:nesting=false --minify) */
  div:before{color:green}:is().foo{color:red}

  /* New output (with --supported:nesting=false --minify) */
  div:before{color:green}
  ```

This input is nonsensical because CSS nesting is (unfortunately) not
supported inside of pseudo-elements such as `:before`. Currently esbuild
generates a rule containing `:is()` in this case when you tell esbuild
to transform nested CSS into non-nested CSS. I think it's reasonable to
do that as it sort of helps explain what's going on (or at least
indicates that something is wrong in the output). It shouldn't be
present in minified code, however, so this release now strips it out.

###
[`v0.25.11`](https://redirect.github.com/evanw/esbuild/blob/HEAD/CHANGELOG.md#02511)

[Compare
Source](https://redirect.github.com/evanw/esbuild/compare/v0.25.10...v0.25.11)

- Add support for `with { type: 'bytes' }` imports
([#&#8203;4292](https://redirect.github.com/evanw/esbuild/issues/4292))

The [import
bytes](https://redirect.github.com/tc39/proposal-import-bytes) proposal
has reached stage 2.7 in the TC39 process, which means that although it
isn't quite recommended for implementation, it's generally approved and
ready for validation. Furthermore it has already been implemented by
[Deno](https://docs.deno.com/examples/importing_bytes/) and
[Webpack](https://redirect.github.com/webpack/webpack/pull/19928). So
with this release, esbuild will also add support for this. It behaves
exactly the same as esbuild's existing [`binary`
loader](https://esbuild.github.io/content-types/#binary). Here's an
example:

  ```js
  import data from './image.png' with { type: 'bytes' }
  const view = new DataView(data.buffer, 0, 24)
  const width = view.getInt32(16)
  const height = view.getInt32(20)
  console.log('size:', width + '\xD7' + height)
  ```

- Lower CSS media query range syntax
([#&#8203;3748](https://redirect.github.com/evanw/esbuild/issues/3748),
[#&#8203;4293](https://redirect.github.com/evanw/esbuild/issues/4293))

With this release, esbuild will now transform CSS media query range
syntax into equivalent syntax using `min-`/`max-` prefixes for older
browsers. For example, the following CSS:

  ```css
  @&#8203;media (640px <= width <= 960px) {
    main {
      display: flex;
    }
  }
  ```

will be transformed like this with a target such as `--target=chrome100`
(or more specifically with `--supported:media-range=false` if desired):

  ```css
  @&#8203;media (min-width: 640px) and (max-width: 960px) {
    main {
      display: flex;
    }
  }
  ```

###
[`v0.25.10`](https://redirect.github.com/evanw/esbuild/blob/HEAD/CHANGELOG.md#02510)

[Compare
Source](https://redirect.github.com/evanw/esbuild/compare/v0.25.9...v0.25.10)

- Fix a panic in a minification edge case
([#&#8203;4287](https://redirect.github.com/evanw/esbuild/issues/4287))

This release fixes a panic due to a null pointer that could happen when
esbuild inlines a doubly-nested identity function and the final result
is empty. It was fixed by emitting the value `undefined` in this case,
which avoids the panic. This case must be rare since it hasn't come up
until now. Here is an example of code that previously triggered the
panic (which only happened when minifying):

  ```js
  function identity(x) { return x }
  identity({ y: identity(123) })
  ```

- Fix `@supports` nested inside pseudo-element
([#&#8203;4265](https://redirect.github.com/evanw/esbuild/issues/4265))

When transforming nested CSS to non-nested CSS, esbuild is supposed to
filter out pseudo-elements such as `::placeholder` for correctness. The
[CSS nesting specification](https://www.w3.org/TR/css-nesting-1/) says
the following:

> The nesting selector cannot represent pseudo-elements (identical to
the behavior of the ':is()' pseudo-class). We’d like to relax this
restriction, but need to do so simultaneously for both ':is()' and '&',
since they’re intentionally built on the same underlying mechanisms.

However, it seems like this behavior is different for nested at-rules
such as `@supports`, which do work with pseudo-elements. So this release
modifies esbuild's behavior to now take that into account:

  ```css
  /* Original code */
  ::placeholder {
    color: red;
    body & { color: green }
    @&#8203;supports (color: blue) { color: blue }
  }

  /* Old output (with --supported:nesting=false) */
  ::placeholder {
    color: red;
  }
  body :is() {
    color: green;
  }
  @&#8203;supports (color: blue) {
     {
      color: blue;
    }
  }

  /* New output (with --supported:nesting=false) */
  ::placeholder {
    color: red;
  }
  body :is() {
    color: green;
  }
  @&#8203;supports (color: blue) {
    ::placeholder {
      color: blue;
    }
  }
  ```

###
[`v0.25.9`](https://redirect.github.com/evanw/esbuild/blob/HEAD/CHANGELOG.md#0259)

[Compare
Source](https://redirect.github.com/evanw/esbuild/compare/v0.25.8...v0.25.9)

- Better support building projects that use Yarn on Windows
([#&#8203;3131](https://redirect.github.com/evanw/esbuild/issues/3131),
[#&#8203;3663](https://redirect.github.com/evanw/esbuild/issues/3663))

With this release, you can now use esbuild to bundle projects that use
Yarn Plug'n'Play on Windows on drives other than the `C:` drive. The
problem was as follows:

1. Yarn in Plug'n'Play mode on Windows stores its global module cache on
the `C:` drive
  2. Some developers put their projects on the `D:` drive
3. Yarn generates relative paths that use `../..` to get from the
project directory to the cache directory
4. Windows-style paths don't support directory traversal between drives
via `..` (so `D:\..` is just `D:`)
5. I didn't have access to a Windows machine for testing this edge case

Yarn works around this edge case by pretending Windows-style paths
beginning with `C:\` are actually Unix-style paths beginning with
`/C:/`, so the `../..` path segments are able to navigate across drives
inside Yarn's implementation. This was broken for a long time in esbuild
but I finally got access to a Windows machine and was able to debug and
fix this edge case. So you should now be able to bundle these projects
with esbuild.

- Preserve parentheses around function expressions
([#&#8203;4252](https://redirect.github.com/evanw/esbuild/issues/4252))

The V8 JavaScript VM uses parentheses around function expressions as an
optimization hint to immediately compile the function. Otherwise the
function would be lazily-compiled, which has additional overhead if that
function is always called immediately as lazy compilation involves
parsing the function twice. You can read [V8's blog post about
this](https://v8.dev/blog/preparser) for more details.

Previously esbuild did not represent parentheses around functions in the
AST so they were lost during compilation. With this change, esbuild will
now preserve parentheses around function expressions when they are
present in the original source code. This means these optimization hints
will not be lost when bundling with esbuild. In addition, esbuild will
now automatically add this optimization hint to immediately-invoked
function expressions. Here's an example:

  ```js
  // Original code
  const fn0 = () => 0
  const fn1 = (() => 1)
  console.log(fn0, function() { return fn1() }())

  // Old output
  const fn0 = () => 0;
  const fn1 = () => 1;
  console.log(fn0, function() {
    return fn1();
  }());

  // New output
  const fn0 = () => 0;
  const fn1 = (() => 1);
  console.log(fn0, (function() {
    return fn1();
  })());
  ```

Note that you do not want to wrap all function expressions in
parentheses. This optimization hint should only be used for functions
that are called on initial load. Using this hint for functions that are
not called on initial load will unnecessarily delay the initial load.
Again, see V8's blog post linked above for details.

- Update Go from 1.23.10 to 1.23.12
([#&#8203;4257](https://redirect.github.com/evanw/esbuild/issues/4257),
[#&#8203;4258](https://redirect.github.com/evanw/esbuild/pull/4258))

This should have no effect on existing code as this version change does
not change Go's operating system support. It may remove certain false
positive reports (specifically CVE-2025-4674 and CVE-2025-47907) from
vulnerability scanners that only detect which version of the Go compiler
esbuild uses.

###
[`v0.25.8`](https://redirect.github.com/evanw/esbuild/blob/HEAD/CHANGELOG.md#0258)

[Compare
Source](https://redirect.github.com/evanw/esbuild/compare/v0.25.7...v0.25.8)

- Fix another TypeScript parsing edge case
([#&#8203;4248](https://redirect.github.com/evanw/esbuild/issues/4248))

This fixes a regression with a change in the previous release that tries
to more accurately parse TypeScript arrow functions inside the `?:`
operator. The regression specifically involves parsing an arrow function
containing a `#private` identifier inside the middle of a `?:` ternary
operator inside a class body. This was fixed by propagating private
identifier state into the parser clone used to speculatively parse the
arrow function body. Here is an example of some affected code:

  ```ts
  class CachedDict {
    #has = (a: string) => dict.has(a);
    has = window
      ? (word: string): boolean => this.#has(word)
      : this.#has;
  }
  ```

- Fix a regression with the parsing of source phase imports

The change in the previous release to parse [source phase
imports](https://redirect.github.com/tc39/proposal-source-phase-imports)
failed to properly handle the following cases:

  ```ts
  import source from 'bar'
  import source from from 'bar'
  import source type foo from 'bar'
  ```

Parsing for these cases should now be fixed. The first case was
incorrectly treated as a syntax error because esbuild was expecting the
second case. And the last case was previously allowed but is now
forbidden. TypeScript hasn't added this feature yet so it remains to be
seen whether the last case will be allowed, but it's safer to disallow
it for now. At least Babel doesn't allow the last case when parsing
TypeScript, and Babel was involved with the source phase import
specification.

###
[`v0.25.7`](https://redirect.github.com/evanw/esbuild/blob/HEAD/CHANGELOG.md#0257)

[Compare
Source](https://redirect.github.com/evanw/esbuild/compare/v0.25.6...v0.25.7)

- Parse and print JavaScript imports with an explicit phase
([#&#8203;4238](https://redirect.github.com/evanw/esbuild/issues/4238))

This release adds basic syntax support for the `defer` and `source`
import phases in JavaScript:

  - `defer`

This is a [stage 3
proposal](https://redirect.github.com/tc39/proposal-defer-import-eval)
for an upcoming JavaScript feature that will provide one way to eagerly
load but lazily initialize imported modules. The imported module is
automatically initialized on first use. Support for this syntax will
also be part of the upcoming release of [TypeScript
5.9](https://devblogs.microsoft.com/typescript/announcing-typescript-5-9-beta/#support-for-import-defer).
The syntax looks like this:

    ```js
    import defer * as foo from "<specifier>";
    const bar = await import.defer("<specifier>");
    ```

Note that this feature deliberately cannot be used with the syntax
`import defer foo from "<specifier>"` or `import defer { foo } from
"<specifier>"`.

  - `source`

This is a [stage 3
proposal](https://redirect.github.com/tc39/proposal-source-phase-imports)
for an upcoming JavaScript feature that will provide another way to
eagerly load but lazily initialize imported modules. The imported module
is returned in an uninitialized state. Support for this syntax may or
may not be a part of TypeScript 5.9 (see [this
issue](https://redirect.github.com/microsoft/TypeScript/issues/61216)
for details). The syntax looks like this:

    ```js
    import source foo from "<specifier>";
    const bar = await import.source("<specifier>");
    ```

Note that this feature deliberately cannot be used with the syntax
`import defer * as foo from "<specifier>"` or `import defer { foo } from
"<specifier>"`.

This change only adds support for this syntax. These imports cannot
currently be bundled by esbuild. To use these new features with
esbuild's bundler, the imported paths must be external to the bundle and
the output format must be set to `esm`.

- Support optionally emitting absolute paths instead of relative paths
([#&#8203;338](https://redirect.github.com/evanw/esbuild/issues/338),
[#&#8203;2082](https://redirect.github.com/evanw/esbuild/issues/2082),
[#&#8203;3023](https://redirect.github.com/evanw/esbuild/issues/3023))

This release introduces the `--abs-paths=` feature which takes a
comma-separated list of situations where esbuild should use absolute
paths instead of relative paths. There are currently three supported
situations: `code` (comments and string literals), `log` (log message
text and location info), and `metafile` (the JSON build metadata).

Using absolute paths instead of relative paths is not the default
behavior because it means that the build results are no longer
machine-independent (which means builds are no longer reproducible).
Absolute paths can be useful when used with certain terminal emulators
that allow you to click on absolute paths in the terminal text and/or
when esbuild is being automatically invoked from several different
directories within the same script.

- Fix a TypeScript parsing edge case
([#&#8203;4241](https://redirect.github.com/evanw/esbuild/issues/4241))

This release fixes an edge case with parsing an arrow function in
TypeScript with a return type that's in the middle of a `?:` ternary
operator. For example:

  ```ts
  x = a ? (b) : c => d;
  y = a ? (b) : c => d : e;
  ```

The `:` token in the value assigned to `x` pairs with the `?` token, so
it's not the start of a return type annotation. However, the first `:`
token in the value assigned to `y` is the start of a return type
annotation because after parsing the arrow function body, it turns out
there's another `:` token that can be used to pair with the `?` token.
This case is notable as it's the first TypeScript edge case that esbuild
has needed a backtracking parser to parse. It has been addressed by a
quick hack (cloning the whole parser) as it's a rare edge case and
esbuild doesn't otherwise need a backtracking parser. Hopefully this is
sufficient and doesn't cause any issues.

- Inline small constant strings when minifying

Previously esbuild's minifier didn't inline string constants because
strings can be arbitrarily long, and this isn't necessarily a size win
if the string is used more than once. Starting with this release,
esbuild will now inline string constants when the length of the string
is three code units or less. For example:

  ```js
  // Original code
  const foo = 'foo'
  console.log({ [foo]: true })

  // Old output (with --minify --bundle --format=esm)
  var o="foo";console.log({[o]:!0});

  // New output (with --minify --bundle --format=esm)
  console.log({foo:!0});
  ```

Note that esbuild's constant inlining only happens in very restrictive
scenarios to avoid issues with TDZ handling. This change doesn't change
when esbuild's constant inlining happens. It only expands the scope of
it to include certain string literals in addition to numeric and boolean
literals.

###
[`v0.25.6`](https://redirect.github.com/evanw/esbuild/blob/HEAD/CHANGELOG.md#0256)

[Compare
Source](https://redirect.github.com/evanw/esbuild/compare/v0.25.5...v0.25.6)

- Fix a memory leak when `cancel()` is used on a build context
([#&#8203;4231](https://redirect.github.com/evanw/esbuild/issues/4231))

Calling `rebuild()` followed by `cancel()` in rapid succession could
previously leak memory. The bundler uses a producer/consumer model
internally, and the resource leak was caused by the consumer being
termianted while there were still remaining unreceived results from a
producer. To avoid the leak, the consumer now waits for all producers to
finish before terminating.

- Support empty `:is()` and `:where()` syntax in CSS
([#&#8203;4232](https://redirect.github.com/evanw/esbuild/issues/4232))

Previously using these selectors with esbuild would generate a warning.
That warning has been removed in this release for these cases.

- Improve tree-shaking of `try` statements in dead code
([#&#8203;4224](https://redirect.github.com/evanw/esbuild/issues/4224))

With this release, esbuild will now remove certain `try` statements if
esbuild considers them to be within dead code (i.e. code that is known
to not ever be evaluated). For example:

  ```js
  // Original code
  return 'foo'
  try { return 'bar' } catch {}

  // Old output (with --minify)
  return"foo";try{return"bar"}catch{}

  // New output (with --minify)
  return"foo";
  ```

- Consider negated bigints to have no side effects

While esbuild currently considers `1`, `-1`, and `1n` to all have no
side effects, it didn't previously consider `-1n` to have no side
effects. This is because esbuild does constant folding with numbers but
not bigints. However, it meant that unused negative bigint constants
were not tree-shaken. With this release, esbuild will now consider these
expressions to also be side-effect free:

  ```js
  // Original code
  let a = 1, b = -1, c = 1n, d = -1n

  // Old output (with --bundle --minify)
  (()=>{var n=-1n;})();

  // New output (with --bundle --minify)
  (()=>{})();
  ```

- Support a configurable delay in watch mode before rebuilding
([#&#8203;3476](https://redirect.github.com/evanw/esbuild/issues/3476),
[#&#8203;4178](https://redirect.github.com/evanw/esbuild/issues/4178))

The `watch()` API now takes a `delay` option that lets you add a delay
(in milliseconds) before rebuilding when a change is detected in watch
mode. If you use a tool that regenerates multiple source files very
slowly, this should make it more likely that esbuild's watch mode won't
generate a broken intermediate build before the successful final build.
This option is also available via the CLI using the `--watch-delay=`
flag.

This should also help avoid confusion about the `watch()` API's options
argument. It was previously empty to allow for future API expansion,
which caused some people to think that the documentation was missing.
It's no longer empty now that the `watch()` API has an option.

- Allow mixed array for `entryPoints` API option
([#&#8203;4223](https://redirect.github.com/evanw/esbuild/issues/4223))

The TypeScript type definitions now allow you to pass a mixed array of
both string literals and object literals to the `entryPoints` API
option, such as `['foo.js', { out: 'lib', in: 'bar.js' }]`. This was
always possible to do in JavaScript but the TypeScript type definitions
were previously too restrictive.

- Update Go from 1.23.8 to 1.23.10
([#&#8203;4204](https://redirect.github.com/evanw/esbuild/issues/4204),
[#&#8203;4207](https://redirect.github.com/evanw/esbuild/pull/4207))

This should have no effect on existing code as this version change does
not change Go's operating system support. It may remove certain false
positive reports (specifically CVE-2025-4673 and CVE-2025-22874) from
vulnerability scanners that only detect which version of the Go compiler
esbuild uses.

- Experimental support for esbuild on OpenHarmony
([#&#8203;4212](https://redirect.github.com/evanw/esbuild/pull/4212))

With this release, esbuild now publishes the
[`@esbuild/openharmony-arm64`](https://www.npmjs.com/package/@&#8203;esbuild/openharmony-arm64)
npm package for
[OpenHarmony](https://en.wikipedia.org/wiki/OpenHarmony). It contains a
WebAssembly binary instead of a native binary because Go doesn't
currently support OpenHarmony. Node does support it, however, so in
theory esbuild should now work on OpenHarmony through WebAssembly.

This change was contributed by
[@&#8203;hqzing](https://redirect.github.com/hqzing).

###
[`v0.25.5`](https://redirect.github.com/evanw/esbuild/blob/HEAD/CHANGELOG.md#0255)

[Compare
Source](https://redirect.github.com/evanw/esbuild/compare/v0.25.4...v0.25.5)

- Fix a regression with `browser` in `package.json`
([#&#8203;4187](https://redirect.github.com/evanw/esbuild/issues/4187))

The fix to
[#&#8203;4144](https://redirect.github.com/evanw/esbuild/issues/4144) in
version 0.25.3 introduced a regression that caused `browser` overrides
specified in `package.json` to fail to override relative path names that
end in a trailing slash. That behavior change affected the
`axios@0.30.0` package. This regression has been fixed, and now has test
coverage.

- Add support for certain keywords as TypeScript tuple labels
([#&#8203;4192](https://redirect.github.com/evanw/esbuild/issues/4192))

Previously esbuild could incorrectly fail to parse certain keywords as
TypeScript tuple labels that are parsed by the official TypeScript
compiler if they were followed by a `?` modifier. These labels included
`function`, `import`, `infer`, `new`, `readonly`, and `typeof`. With
this release, these keywords will now be parsed correctly. Here's an
example of some affected code:

  ```ts
  type Foo = [
    value: any,
    readonly?: boolean, // This is now parsed correctly
  ]
  ```

- Add CSS prefixes for the `stretch` sizing value
([#&#8203;4184](https://redirect.github.com/evanw/esbuild/issues/4184))

This release adds support for prefixing CSS declarations such as `div {
width: stretch }`. That CSS is now transformed into this depending on
what the `--target=` setting includes:

  ```css
  div {
    width: -webkit-fill-available;
    width: -moz-available;
    width: stretch;
  }
  ```

###
[`v0.25.4`](https://redirect.github.com/evanw/esbuild/blob/HEAD/CHANGELOG.md#0254)

[Compare
Source](https://redirect.github.com/evanw/esbuild/compare/v0.25.3...v0.25.4)

- Add simple support for CORS to esbuild's development server
([#&#8203;4125](https://redirect.github.com/evanw/esbuild/issues/4125))

Starting with version 0.25.0, esbuild's development server is no longer
configured to serve cross-origin requests. This was a deliberate change
to prevent any website you visit from accessing your running esbuild
development server. However, this change prevented (by design) certain
use cases such as "debugging in production" by having your production
website load code from `localhost` where the esbuild development server
is running.

To enable this use case, esbuild is adding a feature to allow
[Cross-Origin Resource
Sharing](https://developer.mozilla.org/en-US/docs/Web/HTTP/Guides/CORS)
(a.k.a. CORS) for [simple
requests](https://developer.mozilla.org/en-US/docs/Web/HTTP/Guides/CORS#simple_requests).
Specifically, passing your origin to the new `cors` option will now set
the `Access-Control-Allow-Origin` response header when the request has a
matching `Origin` header. Note that this currently only works for
requests that don't send a preflight `OPTIONS` request, as esbuild's
development server doesn't currently support `OPTIONS` requests.

  Some examples:

  - **CLI:**

    ```
    esbuild --servedir=. --cors-origin=https://example.com
    ```

  - **JS:**

    ```js
    const ctx = await esbuild.context({})
    await ctx.serve({
      servedir: '.',
      cors: {
        origin: 'https://example.com',
      },
    })
    ```

  - **Go:**

    ```go
    ctx, _ := api.Context(api.BuildOptions{})
    ctx.Serve(api.ServeOptions{
      Servedir: ".",
      CORS: api.CORSOptions{
        Origin: []string{"https://example.com"},
      },
    })
    ```

The special origin `*` can be used to allow any origin to access
esbuild's development server. Note that this means any website you visit
will be able to read everything served by esbuild.

- Pass through invalid URLs in source maps unmodified
([#&#8203;4169](https://redirect.github.com/evanw/esbuild/issues/4169))

This fixes a regression in version 0.25.0 where `sources` in source maps
that form invalid URLs were not being passed through to the output.
Version 0.25.0 changed the interpretation of `sources` from file paths
to URLs, which means that URL parsing can now fail. Previously URLs that
couldn't be parsed were replaced with the empty string. With this
release, invalid URLs in `sources` should now be passed through
unmodified.

- Handle exports named `__proto__` in ES modules
([#&#8203;4162](https://redirect.github.com/evanw/esbuild/issues/4162),
[#&#8203;4163](https://redirect.github.com/evanw/esbuild/pull/4163))

In JavaScript, the special property name `__proto__` sets the prototype
when used inside an object literal. Previously esbuild's ESM-to-CommonJS
conversion didn't special-case the property name of exports named
`__proto__` so the exported getter accidentally became the prototype of
the object literal. It's unclear what this affects, if anything, but
it's better practice to avoid this by using a computed property name in
this case.

This fix was contributed by
[@&#8203;magic-akari](https://redirect.github.com/magic-akari).

###
[`v0.25.3`](https://redirect.github.com/evanw/esbuild/blob/HEAD/CHANGELOG.md#0253)

[Compare
Source](https://redirect.github.com/evanw/esbuild/compare/v0.25.2...v0.25.3)

- Fix lowered `async` arrow functions before `super()`
([#&#8203;4141](https://redirect.github.com/evanw/esbuild/issues/4141),
[#&#8203;4142](https://redirect.github.com/evanw/esbuild/pull/4142))

This change makes it possible to call an `async` arrow function in a
constructor before calling `super()` when targeting environments without
`async` support, as long as the function body doesn't reference `this`.
Here's an example (notice the change from `this` to `null`):

  ```js
  // Original code
  class Foo extends Object {
    constructor() {
      (async () => await foo())()
      super()
    }
  }

  // Old output (with --target=es2016)
  class Foo extends Object {
    constructor() {
      (() => __async(this, null, function* () {
        return yield foo();
      }))();
      super();
    }
  }

  // New output (with --target=es2016)
  class Foo extends Object {
    constructor() {
      (() => __async(null, null, function* () {
        return yield foo();
      }))();
      super();
    }
  }
  ```

Some background: Arrow functions with the `async` keyword are
transformed into generator functions for older language targets such as
`--target=es2016`. Since arrow functions capture `this`, the generated
code forwards `this` into the body of the generator function. However,
JavaScript class syntax forbids using `this` in a constructor before
calling `super()`, and this forwarding was problematic since previously
happened even when the function body doesn't use `this`. Starting with
this release, esbuild will now only forward `this` if it's used within
the function body.

This fix was contributed by
[@&#8203;magic-akari](https://redirect.github.com/magic-akari).

- Fix memory leak with `--watch=true`
([#&#8203;4131](https://redirect.github.com/evanw/esbuild/issues/4131),
[#&#8203;4132](https://redirect.github.com/evanw/esbuild/pull/4132))

This release fixes a memory leak with esbuild when `--watch=true` is
used instead of `--watch`. Previously using `--watch=true` caused
esbuild to continue to use more and more memory for every rebuild, but
`--watch=true` should now behave like `--watch` and not leak memory.

This bug happened because esbuild disables the garbage collector when
it's not run as a long-lived process for extra speed, but esbuild's
checks for which arguments cause esbuild to be a long-lived process
weren't updated for the new `--watch=true` style of boolean command-line
flags. This has been an issue since this boolean flag syntax was added
in version 0.14.24 in 2022. These checks are unfortunately separate from
the regular argument parser because of how esbuild's internals are
organized (the command-line interface is exposed as a separate [Go
API](https://pkg.go.dev/github.com/evanw/esbuild/pkg/cli) so you can
build your own custom esbuild CLI).

This fix was contributed by
[@&#8203;mxschmitt](https://redirect.github.com/mxschmitt).

- More concise output for repeated legal comments
([#&#8203;4139](https://redirect.github.com/evanw/esbuild/issues/4139))

Some libraries have many files and also use the same legal comment text
in all files. Previously esbuild would copy each legal comment to the
output file. Starting with this release, legal comments duplicated
across separate files will now be grouped in the output file by unique
comment content.

- Allow a custom host with the development server
([#&#8203;4110](https://redirect.github.com/evanw/esbuild/issues/4110))

With this release, you can now use a custom non-IP `host` with esbuild's
local development server (either with `--serve=` for the CLI or with the
`serve()` call for the API). This was previously possible, but was
intentionally broken in [version
0.25.0](https://redirect.github.com/evanw/esbuild/releases/v0.25.0) to
fix a security issue. This change adds the functionality back except
that it's now opt-in and only for a single domain name that you provide.

  For example,

</details>

---

### Configuration

📅 **Schedule**: (in timezone America/Chicago)

- Branch creation
  - Only on Friday (`* * * * 5`)
- Automerge
  - At any time (no schedule defined)

🚦 **Automerge**: Enabled.

♻ **Rebasing**: Whenever PR is behind base branch, or you tick the
rebase/retry checkbox.

🔕 **Ignore**: Close this PR and you won't be reminded about this update
again.

---

- [ ] <!-- rebase-check -->If you want to rebase/retry this PR, check
this box

---

This PR was generated by [Mend Renovate](https://mend.io/renovate/).
View the [repository job
log](https://developer.mend.io/github/jdx/mise).

<!--renovate-debug:eyJjcmVhdGVkSW5WZXIiOiI0My4xMTAuMiIsInVwZGF0ZWRJblZlciI6IjQzLjExMC4yIiwidGFyZ2V0QnJhbmNoIjoibWFpbiIsImxhYmVscyI6W119-->

Co-authored-by: renovate[bot] <29139614+renovate[bot]@users.noreply.github.com>

Author: renovate[bot]

bun.lock

@@ -17,7 +17,7 @@
   },
   "author": "@jdx",
   "resolutions": {
-    "esbuild": "0.21.5"
+    "esbuild": "0.28.0"
   },
   "devDependencies": {
     "@fig/eslint-config-autocomplete": "^2.0.0",