fix(deps): update module github.com/evanw/esbuild to v0.27.0

[renovate-sh-app]

This PR contains the following updates:

Package	Change	Age	Confidence
github.com/evanw/esbuild	v0.25.10 -> v0.27.0

---

Release Notes

evanw/esbuild (github.com/evanw/esbuild)

v0.27.0

Compare Source

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 for more information.

• Use Uint8Array.fromBase64 if available (#​4286)

  With this release, esbuild's binary loader will now use the new 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 (#​4208, #​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

Compare Source

• Enable trusted publishing (#​4281)

  GitHub and npm are recommending that maintainers for packages such as esbuild switch to trusted publishing. 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

Compare Source

• Fix a minification regression with CSS media queries (#​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 (#​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:

  • Atomics
  • SharedArrayBuffer

  From ES2020:

  • BigInt64Array
  • BigUint64Array

  From ES2021:

  • FinalizationRegistry
  • WeakRef

  From ES2025:

  • 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:

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

• Add support for the new @view-transition CSS rule (#​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):

  /* Original code */
  @​view-transition {
    navigation: auto;
    types: check;
  }
  
  /* Old output */
  @​view-transition { navigation: auto; types: check; }
  
  /* New output */
  @​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.

  This change was contributed by @​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:

  /* 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

Compare Source

• Add support for with { type: 'bytes' } imports (#​4292)

  The 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 and Webpack. So with this release, esbuild will also add support for this. It behaves exactly the same as esbuild's existing binary loader. Here's an example:

  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 (#​3748, #​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:

  @&#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):

  @​media (min-width: 640px) and (max-width: 960px) {
    main {
      display: flex;
    }
  }

---

Configuration

📅 Schedule: Branch creation - Between 12:00 AM and 03:59 AM, only on Monday ( * 0-3 * * 1 ) (UTC), Automerge - At any time (no schedule defined).

🚦 Automerge: Disabled by config. Please merge this manually once you are satisfied.

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

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

---

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

---

Need help?

You can ask for more help in the following Slack channel: #proj-renovate-self-hosted. In that channel you can also find ADR and FAQ docs in the Resources section.

[inancgumus]

No issues with this one, except for the usual flaky tests.

[joanlopez]

Given the release notes, I'm wondering if we do really want to update to v0.26.0 or only to the latest patch, and wait for the next minor/patch to move to v0.26.x. Wdyt @AgnesToulet?
cc/ @grafana/k6-core

[codebien]

@joanlopez It sounds a good idea to me considering how many patches esbuild project releases. Can you add a rule to the renovate config, please? We do the same thing for Go so you can just copy the rule.

[joanlopez]

@codebien I didn't really mean to always wait for .1 releases, but in this specific case, because apparently v0.26.0 has no code/feature changes (see the release notes).

But if somebody confirms we really to apply that for all the minors, then I'll create the rule, yeah.

[codebien]

because apparently v0.26.0 has no code/feature changes (see the release notes)

Ah, I missed that. It seems you're right, we shouldn't merge this pull request in any case.