This PR may introduce breaking changes that require manual intervention. In such cases, you will need to check out this branch, fix the cause of the breakage, and commit the fix to ensure a green CI build. To check out and update this PR, follow the steps below:

# Check out the PR branch
git checkout -b renovate/esbuild-devdependencies main
git pull https://github.com/ampproject/amphtml.git renovate/esbuild-devdependencies

# Directly make fixes and commit them
amp lint --fix # For lint errors in JS files
amp prettify --fix # For prettier errors in non-JS files
# Edit source code in case of new compiler warnings / errors

# Push the changes to the branch
git push git@github.com:ampproject/amphtml.git renovate/esbuild-devdependencies:renovate/esbuild-devdependencies

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;

v0.12.17

Compare Source

• Fix a bug with private fields and logical assignment operators (#​1418)

  This release fixes a bug where code using private fields in combination with logical assignment operators was transformed incorrectly if the target environment supported logical assignment operators but not private fields. Since logical assignment operators are assignment operators, the entire operator must be transformed even if the operator is supported. This should now work correctly:

  // Original code
  class Foo {
    #x
    foo() {
      this.#x &&= 2
      this.#x ||= 2
      this.#x ??= 2
    }
  }
  
  // Old output
  var _x;
  class Foo {
    constructor() {
      __privateAdd(this, _x, void 0);
    }
    foo() {
      this._x &&= 2;
      this._x ||= 2;
      this._x ??= 2;
    }
  }
  _x = new WeakMap();
  
  // New output
  var _x, _a;
  class Foo {
    constructor() {
      __privateAdd(this, _x, void 0);
    }
    foo() {
      __privateGet(this, _x) && __privateSet(this, _x, 2);
      __privateGet(this, _x) || __privateSet(this, _x, 2);
      __privateGet(this, _x) ?? __privateSet(this, _x, 2);
    }
  }
  _x = new WeakMap();

• Fix a hoisting bug in the bundler (#​1455)

  This release fixes a bug where variables declared using var inside of top-level for loop initializers were not hoisted inside lazily-initialized ES modules (such as those that are generated when bundling code that loads an ES module using require). This meant that hoisted function declarations incorrectly didn't have access to these loop variables:

  // entry.js
  console.log(require('./esm-file').test())
  
  // esm-file.js
  for (var i = 0; i < 10; i++) ;
  export function test() { return i }

  Old output (incorrect):

  // esm-file.js
  var esm_file_exports = {};
  __export(esm_file_exports, {
    test: () => test
  });
  function test() {
    return i;
  }
  var init_esm_file = __esm({
    "esm-file.js"() {
      for (var i = 0; i < 10; i++)
        ;
    }
  });
  
  // entry.js
  console.log((init_esm_file(), esm_file_exports).test());

  New output (correct):

  // esm-file.js
  var esm_file_exports = {};
  __export(esm_file_exports, {
    test: () => test
  });
  function test() {
    return i;
  }
  var i;
  var init_esm_file = __esm({
    "esm-file.js"() {
      for (i = 0; i < 10; i++)
        ;
    }
  });
  
  // entry.js
  console.log((init_esm_file(), esm_file_exports).test());

• Fix a code generation bug for private methods (#​1424)

  This release fixes a bug where when private methods are transformed and the target environment is one that supports private methods (such as esnext), the member function name was uninitialized and took on the zero value by default. This resulted in the member function name becoming __create instead of the correct name since that's the name of the symbol at index 0. Now esbuild always generates a private method symbol even when private methods are supported, so this is no longer an issue:

  // Original code
  class Foo {
    #a() { return 'a' }
    #b() { return 'b' }
    static c
  }
  
  // Old output
  var _a, __create, _b, __create;
  var Foo = class {
    constructor() {
      __privateAdd(this, _a);
      __privateAdd(this, _b);
    }
  };
  _a = new WeakSet();
  __create = function() {
    return "a";
  };
  _b = new WeakSet();
  __create = function() {
    return "b";
  };
  __publicField(Foo, "c");
  
  // New output
  var _a, a_fn, _b, b_fn;
  var Foo = class {
    constructor() {
      __privateAdd(this, _a);
      __privateAdd(this, _b);
    }
  };
  _a = new WeakSet();
  a_fn = function() {
    return "a";
  };
  _b = new WeakSet();
  b_fn = function() {
    return "b";
  };
  __publicField(Foo, "c");

• The CLI now stops watch and serve mode when stdin is closed (#​1449)

  To facilitate esbuild being called from the Erlang VM, esbuild's command-line interface will now exit when in --watch or --serve mode if stdin is closed. This change is necessary because the Erlang VM doesn't have an API for terminating a child process, so it instead closes stdin to indicate that the process is no longer needed.

  Note that this only happens when stdin is not a TTY (i.e. only when the CLI is being used non-interactively) to avoid disrupting the use case of manually moving esbuild to a background job using a Unix terminal.

  This change was contributed by @​josevalim.

v0.12.16

Compare Source

• Remove warning about bad CSS @-rules (#​1426)

  The CSS bundler built in to esbuild is only designed with real CSS in mind. Running other languages that compile down to CSS through esbuild without compiling them down to CSS first can be a bad idea since esbuild applies browser-style error recovery to invalid syntax and uses browser-style import order that other languages might not be expecting. This is why esbuild previously generated warnings when it encountered unknown CSS @-rules.

  However, some people want to run other non-CSS languages through esbuild's CSS bundler anyway. So with this release, esbuild will no longer generate any warnings if you do this. But keep in mind that doing this is still potentially unsafe. Depending on the input language, using esbuild's CSS bundler to bundle non-CSS code can still potentially alter the semantics of your code.

• Allow ES2021 in tsconfig.json (#​1470)

  TypeScript recently added support for ES2021 in tsconfig.json so esbuild now supports this too. This has the same effect as if you passed --target=es2021 to esbuild. Keep in mind that the value of target in tsconfig.json is only respected if you did not pass a --target= value to esbuild.

• Avoid using the worker_threads optimization in certain old node versions (#​1462)

  The worker_threads optimization makes esbuild's synchronous API calls go much faster than they would otherwise. However, it turns out this optimization cannot be used in certain node versions older than v12.17.0, where node throws an error when trying to create the worker. This optimization is now disabled in these scenarios.

  Note that these old node versions are currently in maintenance. I recommend upgrading to a modern version of node if run-time performance is important to you.

• Paths starting with node: are implicitly external when bundling for node (#​1466)

  This replicates a new node feature where you can prefix an import path with node: to load a native node module by that name (such as import fs from "node:fs/promises"). These paths also have special behavior:

  Core modules can also be identified using the node: prefix, in which case it bypasses the require cache. For instance, require('node:http') will always return the built in HTTP module, even if there is require.cache entry by that name.

  With this release, esbuild's built-in resolver will now automatically consider all import paths starting with node: as external. This new behavior is only active when the current platform is set to node such as with --platform=node. If you need to customize this behavior, you can write a plugin to intercept these paths and treat them differently.

• Consider \ and / to be the same in file paths (#​1459)

  On Windows, there are many different file paths that can refer to the same underlying file. Windows uses a case-insensitive file system so for example foo.js and Foo.js are the same file. When bundling, esbuild needs to treat both of these paths as the same to avoid incorrectly bundling the file twice. This is case is already handled by identifying files by their lower-case file path.

  The case that wasn't being handled is the fact that Windows supports two different path separators, / and \, both of which mean the same thing. For example foo/bar.js and foo\bar.js are the same file. With this release, this case is also handled by esbuild. Files that are imported in multiple places with inconsistent path separators will now be considered the same file instead of bundling the file multiple times.

v0.12.15

Compare Source

• Fix a bug with var() in CSS color lowering (#​1421)

  This release fixes a bug with esbuild's handling of the rgb and hsl color functions when they contain var(). Each var() token sequence can be substituted for any number of tokens including zero or more than one, but previously esbuild's output was only correct if each var() inside of rgb or hsl contained exactly one token. With this release, esbuild will now not attempt to transform newer CSS color syntax to older CSS color syntax if it contains var():

  /* Original code */
  a {
    color: hsl(var(--hs), var(--l));
  }
  
  /* Old output */
  a {
    color: hsl(var(--hs), ,, var(--l));
  }
  
  /* New output */
  a {
    color: hsl(var(--hs), var(--l));
  }
  

  The bug with the old output above happened because esbuild considered the arguments to hsl as matching the pattern hsl(h s l) which is the new space-separated form allowed by CSS Color Module Level 4. Then esbuild tried to convert this to the form hsl(h, s, l) which is more widely supported by older browsers. But this substitution doesn't work in the presence of var(), so it has now been disabled in that case.

v0.12.14

Compare Source

• Fix the file loader with custom namespaces (#​1404)

  This fixes a regression from version 0.12.12 where using a plugin to load an input file with the file loader in a custom namespace caused esbuild to write the contents of that input file to the path associated with that namespace instead of to a path inside of the output directory. With this release, the file loader should now always copy the file somewhere inside of the output directory.

v0.12.13

Compare Source

• Fix using JS synchronous API from from non-main threads (#​1406)

  This release fixes an issue with the new implementation of the synchronous JS API calls (transformSync and buildSync) when they are used from a thread other than the main thread. The problem happened because esbuild's new implementation uses node's worker_threads library internally and non-main threads were incorrectly assumed to be esbuild's internal thread instead of potentially another unrelated thread. Now esbuild's synchronous JS APIs should work correctly when called from non-main threads.

v0.12.12

Compare Source

• Fix file loader import paths when subdirectories are present (#​1044)

  Using the file loader for a file type causes importing affected files to copy the file into the output directory and to embed the path to the copied file into the code that imported it. However, esbuild previously always embedded the path relative to the output directory itself. This is problematic when the importing code is generated within a subdirectory inside the output directory, since then the relative path is wrong. For example:

  $ cat src/example/entry.css
  div {
    background: url(../images/image.png);
  }
  
  $ esbuild --bundle src/example/entry.css --outdir=out --outbase=src --loader:.png=file
  
  $ find out -type f
  out/example/entry.css
  out/image-55DNWN2R.png
  
  $ cat out/example/entry.css
  /* src/example/entry.css */
  div {
    background: url(./image-55DNWN2R.png);
  }
  

  This is output from the previous version of esbuild. The above asset reference in out/example/entry.css is wrong. The path should start with ../ because the two files are in different directories.

  With this release, the asset references present in output files will now be the full relative path from the output file to the asset, so imports should now work correctly when the entry point is in a subdirectory within the output directory. This change affects asset reference paths in both CSS and JS output files.

  Note that if you want asset reference paths to be independent of the subdirectory in which they reside, you can use the --public-path setting to provide the common path that all asset reference paths should be constructed relative to. Specifically --public-path=. should bring back the old problematic behavior in case you need it.

• Add support for [dir] in --asset-names (#​1196)

  You can now use path templates such as --asset-names=[dir]/[name]-[hash] to copy the input directory structure of your asset files (i.e. input files loaded with the file loader) to the output directory. Here's an example:

  $ cat entry.css
  header {
    background: url(images/common/header.png);
  }
  main {
    background: url(images/home/hero.png);
  }
  
  $ esbuild --bundle entry.css --outdir=out --asset-names=[dir]/[name]-[hash] --loader:.png=file
  
  $ find out -type f
  out/images/home/hero-55DNWN2R.png
  out/images/common/header-55DNWN2R.png
  out/entry.css
  
  $ cat out/entry.css
  /* entry.css */
  header {
    background: url(./images/common/header-55DNWN2R.png);
  }
  main {
    background: url(./images/home/hero-55DNWN2R.png);
  }