chore(deps): update dependency esbuild to v0.12.24

[renovate]

This PR contains the following updates:

Package	Change	Age	Adoption	Passing	Confidence
esbuild	0.12.17 -> 0.12.24

---

Release Notes

evanw/esbuild

v0.12.24

Compare Source

• Fix an edge case with direct eval and variable renaming

  Use of the direct eval construct causes all variable names in the scope containing the direct eval and all of its parent scopes to become "pinned" and unable to be renamed. This is because the dynamically-evaluated code is allowed to reference any of those variables by name. When this happens esbuild avoids renaming any of these variables, which effectively disables minification for most of the file, and avoids renaming any non-pinned variables to the name of a pinned variable.

  However, there was previously a bug where the pinned variable name avoidance only worked for pinned variables in the top-level scope but not in nested scopes. This could result in a non-pinned variable being incorrectly renamed to the name of a pinned variable in certain cases. For example:

  // Input to esbuild
  return function($) {
    function foo(arg) {
      return arg + $;
    }
    // Direct "eval" here prevents "$" from being renamed
    // Repeated "$" puts "$" at the top of the character frequency histogram
    return eval(foo($$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$))
  }(2);

  When this code is minified with --minify-identifiers, the non-pinned variable arg is incorrectly transformed into $ resulting in a name collision with the nested pinned variable $:

  // Old output from esbuild (incorrect)
  return function($) {
    function foo($) {
      return $ + $;
    }
    return eval(foo($$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$));
  }(2);

  This is because the non-pinned variable arg is renamed to the top character in the character frequency histogram $ (esbuild uses a character frequency histogram for smaller gzipped output sizes) and the pinned variable $ was incorrectly not present in the list of variable names to avoid. With this release, the output is now correct:

  // New output from esbuild (correct)
  return function($) {
    function foo(n) {
      return n + $;
    }
    return eval(foo($$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$));
  }(2);

  Note that even when esbuild handles direct eval correctly, using direct eval is not recommended because it disables minification for the file and likely won't work correctly in the presence of scope hoisting optimizations. See https://esbuild.github.io/link/direct-eval for more details.

v0.12.23

Compare Source

• Parsing of rest arguments in certain TypeScript types (#​1553)

  This release implements parsing of rest arguments inside object destructuring inside arrow functions inside TypeScript type declarations. Support for rest arguments in this specific syntax was not previously implemented. The following code was incorrectly considered a syntax error before this release, but is no longer considered a syntax error:

  type F = ({ ...rest }) => void;

• Fix error message for watch: true and buildSync (#​1552)

  Watch mode currently only works with the build API. Previously using watch mode with the buildSync API caused a confusing error message. This release explicitly disallows doing this, so the error message is now more clear.

• Fix an minification bug with the --keep-names option (#​1552)

  This release fixes a subtle bug that happens with --keep-names --minify and nested function declarations in strict mode code. It can be triggered by the following code, which was being compiled incorrectly under those flags:

  export function outer() {
    {
      function inner() {
        return Math.random();
      }
      const x = inner();
      console.log(x);
    }
  }
  outer();

  The bug was caused by an unfortunate interaction between a few of esbuild's behaviors:

  1. Function declarations inside of nested scopes behave differently in different situations, so esbuild rewrites this function declaration to a local variable initialized to a function expression instead so that it behaves the same in all situations.

     More specifically, the interpretation of such function declarations depends on whether or not it currently exists in a strict mode context:

     > (function(){ { function x(){} } return x })()
     function x() {}
     
     > (function(){ 'use strict'; { function x(){} } return x })()
     ❌ Uncaught ReferenceError: x is not defined
     

     The bundling process sometimes erases strict mode context. For example, different files may have different strict mode status but may be merged into a single file which all shares the same strict mode status. Also, files in ESM format are automatically in strict mode but a bundle output file in IIFE format may not be executed in strict mode. Transforming the nested function to a let in strict mode and a var in non-strict mode means esbuild's output will behave reliably in different environments.

  2. The "keep names" feature adds automatic calls to the built-in __name helper function to assign the original name to the .name property of the minified function object at run-time. That transforms the code into this:

     let inner = function() {
       return Math.random();
     };
     __name(inner, "inner");
     const x = inner();
     console.log(x);

     This injected helper call does not count as a use of the associated function object so that dead-code elimination will still remove the function object as dead code if nothing else uses it. Otherwise dead-code elimination would stop working when the "keep names" feature is enabled.

  3. Minification enables an optimization where an initialized variable with a single use immediately following that variable is transformed by inlining the initializer into the use. So for example var a = 1; return a is transformed into return 1. This code matches this pattern (initialized single-use variable + use immediately following that variable) so the optimization does the inlining, which transforms the code into this:

     __name(function() {
       return Math.random();
     }, "inner");
     const x = inner();
     console.log(x);

     The code is now incorrect because inner actually has two uses, although only one was actually counted.

  This inlining optimization will now be avoided in this specific case, which fixes the bug without regressing dead-code elimination or initialized variable inlining in any other cases.

v0.12.22

Compare Source

• Make HTTP range requests more efficient (#​1536)

  The local HTTP server built in to esbuild supports range requests, which are necessary for video playback in Safari. This means you can now use <video> tags in your HTML pages with esbuild's local HTTP server.

  Previously this was implemented inefficiently for files that aren't part of the build, but that are read from the underlying fallback directory. In that case the entire file was being read even though only part of the file was needed. In this release, only the part of the file that is needed is read so using HTTP range requests with esbuild in this case will now use less memory.

• Fix CSS minification bug with box-shadow and var() (#​1538)

  The box-shadow property can be specified using 2, 3, or 4 numbers. The 3rd and 4th numbers are the blur radius and spread radius, and can be omitted if zero. When minifying, esbuild has an optimization that removes trailing zeros from runs of numbers within the box-shadow property. However, that optimization is not correct in the presence of tokens that are neither a number, a color, nor the token insert. These edge cases include var() or calc() tokens. With this release, esbuild will now do stronger validation and will only remove trailing zeros if the contents of the box-shadow property matches the underlying CSS grammar exactly.

  /* Original code */
  button {
    box-shadow: 0 0 0 var(--spread) red;
  }
  
  /* Old minified output */
  button{box-shadow:0 0 var(--spread) red}
  
  /* New minified output */
  button{box-shadow:0 0 0 var(--spread) red}

v0.12.21

Compare Source

• Add support for native esbuild on Windows 64-bit ARM (#​995)

  The newly-released Go version 1.17.0 adds support for Windows 64-bit ARM CPUs, so esbuild can now support these CPUs as well. This release introduces support for npm install esbuild on Windows 64-bit ARM.

v0.12.20

Compare Source

• Avoid the sequence </style in CSS output (#​1509)

  The CSS code generator now avoids generating the character sequence </style in case you want to embed the CSS output in a <style>...</style> tag inside HTML:

  /* Original code */
  a:after {
    content: "</style>";
  }
  
  /* Old output */
  a:after {
    content: "</style>";
  }
  
  /* New output */
  a:after {
    content: "<\/style>";
  }

  This mirrors how the JS code generator similarly avoids the character sequence </script.

  In addition, the check that escapes </style and </script is now case-insensitive to match how the browser's HTML parser behaves. So </STYLE and </SCRIPT are now escaped as well.

• Fix a TypeScript parsing edge case with ASI (Automatic Semicolon Insertion) (#​1512)

  This fixes a parsing bug where TypeScript types consisting of multiple identifiers joined together with a . could incorrectly extend onto the next line if the next line started with <. This problem was due to ASI; esbuild should be automatically inserting a semicolon at the end of the line:

  let x: {
    <A extends B>(): c.d /* A semicolon should be automatically inserted here */
    <E extends F>(): g.h
  }

  Previously the above code was incorrectly considered a syntax error since esbuild attempted to parse the parameterized type c.d<E extends F ? ...>. With this release, this code is now parsed correctly.

v0.12.19

Compare Source

• Add support for CSS source maps (#​519)

  With this release, esbuild will now generate source maps for CSS output files when --sourcemap is enabled. This supports all of the same options as JS source maps including --sourcemap=inline and --sourcemap=external. In addition, CSS input files with embedded /*# sourceMappingURL=... */ comments will cause the CSS output file source map to map all the way back to the original inputs. CSS source maps are used by the browser's style inspector to link back to the original source code instead of linking to the bundled source code.

• Fix computed class fields in TypeScript edge case (#​1507)

  If TypeScript code contains computed class fields, the target environment supports class fields so syntax lowering is not necessary, and TypeScript's useDefineForClassFields setting is set to true, then esbuild had a bug where the computed property names were computed after the class definition and were undefined. Note that TypeScript's useDefineForClassFields setting defaults to true if tsconfig.json contains "target": "ESNext".

  // Original code
  class Foo {
    [foo] = 1;
    @​bar [baz] = 2;
  }
  
  // Old output
  var _a, _b;
  var Foo = class {
    [_a] = 1;
    [_b] = 2;
  };
  _a = foo, _b = baz;
  __decorateClass([
    bar
  ], Foo.prototype, _b, 2);
  
  // New output
  var _a;
  var Foo = class {
    [foo] = 1;
    [_a = baz] = 2;
  };
  __decorateClass([
    bar
  ], Foo.prototype, _a, 2);

  The problem in this case is that normally TypeScript moves class field initializers into the special constructor method (automatically generating one if one doesn't already exist) so the side effects for class field property names must happen after the class body. But if class fields are supported by the target environment then the side effects must happen inline instead.

v0.12.18

Compare Source

• Allow implicit ./ in CSS @import paths (#​1494)

  In the browser, the paths inside CSS @import rules are implicitly relative to the path of the current CSS style sheet. Previously esbuild used node's JS path resolution rules in CSS as well, which required a ./ or ../ prefix for a path to be considered a relative path. Paths without that prefix are considered package paths and are searched for inside node_modules instead.

  With this release, esbuild will now first try to interpret the path as a relative path and then fall back to interpreting it as a package path if nothing exists at that relative path. This feature was originally added in version 0.7.18 but only worked for CSS url() tokens. In this release it now also works for @import rules.

  This feature was contributed by @​pd4d10.

• Fix lowering of nullish coalescing assignment edge case (#​1493)

  This release fixes a bug where lowering of the ??= nullish coalescing assignment operator failed when the target environment supported nullish coalescing and private class fields but not nullish coalescing assignment. An example target environment with this specific feature support matrix combination is node 14.8. This edge case is now lowered correctly:

  // Original code
  class A {
    #a;
    f() {
      this.#a ??= 1;
    }
  }
  
  // Old output (with --target=node14.8)
  panic: Unexpected expression of type *js_ast.EPrivateIdentifier
  
  // New output (with --target=node14.8)
  class A {
    #a;
    f() {
      this.#a ?? (this.#a = 1);
    }
  }

• Fix public fields being inserted before super() call (#​1497)

  The helper function that esbuild uses to emulate the new public class field syntax can potentially be inserted into the class constructor before the super() call. That is problematic because the helper function makes use of this, and this must only be used after the super() call. This release fixes a case where this happens when minification is enabled:

  // Original code
  class A extends B {
    x;
    constructor() {
      f();
      super();
    }
  }
  
  // Old output (with --minify-syntax --target=es6)
  class A extends B {
    constructor() {
      __publicField(this, "x");
      f(), super();
    }
  }
  
  // New output (with --minify-syntax --target=es6)
  class A extends B {
    constructor() {
      f();
      super();
      __publicField(this, "x");
    }
  }

• Fix lowering of static private methods in class expressions (#​1498)

  Previously static private methods were lowered incorrectly when present in class expressions. The class expression itself was missing in the output due to an oversight (variable shadowing). This issue has been fixed:

  // Original code
  (class {
    static #x() {}
  });
  
  // Old output (with --target=es6)
  var _x, _a, x_fn;
  __privateAdd(_a, _x), _x = new WeakSet(), x_fn = function() {
  }, __privateAdd(_a, _x), _a;
  
  // New output (with --target=es6)
  var _x, _a, x_fn;
  _a = class {
  }, _x = new WeakSet(), x_fn = function() {
  }, __privateAdd(_a, _x), _a;

---

Configuration

📅 Schedule: 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.

---

This PR has been generated by WhiteSource Renovate. View repository job log here.

[angular-automatic-lock-bot]

This issue has been automatically locked due to inactivity.
Please file a new issue if you are encountering a similar or related problem.

Read more about our automatic conversation locking policy.

_{This action has been performed automatically by a bot.}