Build fails with "Transforming destructuring is not supported yet" after @angular/build 19.2.25

[adrenaline15]

Command

build

Is this a regression?

• Yes, this behavior used to work in the previous version

The previous version in which this bug was not present was

@angular/build 19.2.20

Description

@angular/build@19.2.25 bumped its esbuild dependency from 0.25.4 to 0.28.0. This causes builds to fail when the browserslist includes targets like iOS >= 14 or Chrome >= 79:

✘ [ERROR] Transforming destructuring to the configured target environment
  ("chrome79.0", "edge141.0", "firefox140.0", "ios14.0", "safari18.0") is not supported yet
    node_modules/zone.js/fesm2015/zone.js:140:12:
      140 │       const {
          ╵             ^

All configured targets support destructuring natively (Chrome since 49, iOS Safari since 10). esbuild 0.28+ intentionally errors when it encounters syntax it cannot downlevel (evanw/esbuild#4436, closed as "not planned"), but @angular/build does not set supported: { destructuring: true } to inform esbuild that no lowering is needed.
Vite encountered the same issue and shipped a fix in vitejs/vite#22346 by setting supported.destructuring: true when targets are above the buggy Safari range (Safari >= 14.1 / iOS >= 14.5).

Workaround: add "overrides": { "esbuild": "0.27.4" } to package.json.

Suggested fix: Apply the same approach as Vite — set supported: { destructuring: true } in the esbuild options when browserslist targets are above Safari 14.0 / iOS 14.4.

Related issues:

• esbuild just broke all my builds evanw/esbuild#4436 — intentional behavior in esbuild 0.28+
• Allow destructuring for all target environments evanw/esbuild#3743 — open feature request for destructuring transform
• fix: avoid destructure lowering for newer safari vitejs/vite#22346 — Vite's fix for the same problem

Minimal Reproduction

1. ng new repro-app --style=css --routing=false --ssr=false
2. Add .browserslistrc in the project root with the following content:

   Chrome >= 79
   iOS >= 14.0
   last 2 Safari major versions
   

3. Ensure @angular/build@19.2.25 is installed (check package-lock.json)
4. Run ng build
   Expected: Build succeeds — all targets support destructuring natively.
   Actual: Build fails with:

✘ [ERROR] Transforming destructuring to the configured target environment
  ("chrome79.0", "ios14.0", ...) is not supported yet
    node_modules/zone.js/fesm2015/zone.js:140:12

Note: The error is triggered by any dependency using const { ... } = syntax (e.g., zone.js/fesm2015/zone.js, swiper). Reverting to @angular/build@19.2.20 (which uses esbuild 0.25.4) resolves the issue.

Exception or Error

✘ [ERROR] Transforming destructuring to the configured target environment ("chrome79.0", "ios14.0", "safari18.0" + 5 overrides) is not supported yet

Your Environment

Angular CLI: 19.2.20
@angular/build: 19.2.25 (esbuild 0.28.0)
Node: 22.x
OS: macOS / Linux
.browserslistrc:
  Chrome >= 79
  last 1 Firefox version
  last 2 Edge major versions
  last 2 Safari major versions
  iOS >= 14.0
  Firefox ESR

Anything else relevant?

No response

[alan-agius4]

The current error is actually beneficial as it catches a runtime issue early. While the Vite workaround bypasses the build error, it results in code that fails during execution. The root cause is that the specified browsers do not meet the minimum supported versions by Angular.

[adrenaline15]

Acknowledged — iOS >= 14 is below Angular's recommended "2 most recent major versions." I am in the process of upgrading my minimum targets to iOS >= 15 / Safari >= 15, which resolves this.

That said, the same browserslist builds successfully on @angular/build@19.2.20 and fails on 19.2.25. Regardless of whether these targets are officially supported, a change that turns a working build into a hard failure is a breaking change — and should not land in a patch release without documentation or migration guidance.

[alan-agius4]

@adrenaline15, although the build completes, the resulting app won't function on these browsers.

@dgp1130 what's your take on this?

[dgp1130]

My interpretation from reading the esbuild issue is that it was a bug that esbuild allowed the build to pass originally, given that it wouldn't work at runtime on those browsers. This bug was "fixed" by moving the error from runtime to build time.

I get that it's maybe more breaking for the unaffected browsers by nature of breaking the entire build, but the increased visibility that your app is broken on those browsers you've stated you want to support is probably worth that impact IMHO. I'm sympathetic that a patch version is introducing a build error, but it is already broken at runtime before that patch version, so this is just moving the error for visibility more so than actually creating a new failure mode. I'm inclined to treat this as a bug fix rather than a breaking change, so I don't think there's any action we need to take in response.