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

[renovate]

This PR contains the following updates:

Package	Change	Age	Adoption	Passing	Confidence
esbuild	0.12.5 -> 0.12.17

---

Release Notes

evanw/esbuild

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);
  }
  

v0.12.11

Compare Source

• Enable faster synchronous transforms with the JS API by default (#​1000)

  Currently the synchronous JavaScript API calls transformSync and buildSync spawn a new child process on every call. This is due to limitations with node's child_process API. Doing this means transformSync and buildSync are much slower than transform and build, which share the same child process across calls.

  This release improves the performance of transformSync and buildSync by up to 20x. It enables a hack where node's worker_threads API and atomics are used to block the main thread while asynchronous communication with a single long-lived child process happens in a worker. Previously this was only enabled when the ESBUILD_WORKER_THREADS environment variable was set to 1. But this experiment has been available for a while (since version 0.9.6) without any reported issues. Now this hack will be enabled by default. It can be disabled by setting ESBUILD_WORKER_THREADS to 0 before running node.

• Fix nested output directories with WebAssembly on Windows (#​1399)

  Many functions in Go's standard library have a bug where they do not work on Windows when using Go with WebAssembly. This is a long-standing bug and is a fault with the design of the standard library, so it's unlikely to be fixed. Basically Go's standard library is designed to bake "Windows or not" decision into the compiled executable, but WebAssembly is platform-independent which makes "Windows or not" is a run-time decision instead of a compile-time decision. Oops.

  I have been working around this by trying to avoid using path-related functions in the Go standard library and doing all path manipulation by myself instead. This involved completely replacing Go's path/filepath library. However, I missed the os.MkdirAll function which is also does path manipulation but is outside of the path/filepath package. This meant that nested output directories failed to be created on Windows, which caused a build error. This problem only affected the esbuild-wasm package.

  This release manually reimplements nested output directory creation to work around this bug in the Go standard library. So nested output directories should now work on Windows with the esbuild-wasm package.

v0.12.10

Compare Source

• Add a target for ES2021

  It's now possible to use --target=es2021 to target the newly-released JavaScript version ES2021. The only difference between that and --target=es2020 is that logical assignment operators such as a ||= b are not converted to regular assignment operators such as a || (a = b).

• Minify the syntax Infinity to 1 / 0 (#​1385)

  The --minify-syntax flag (automatically enabled by --minify) will now minify the expression Infinity to 1 / 0, which uses fewer bytes:

  // Original code
  const a = Infinity;
  
  // Output with "--minify-syntax"
  const a = 1 / 0;

  This change was contributed by @​Gusted.

• Minify syntax in the CSS transform property (#​1390)

  This release includes various size reductions for CSS transform matrix syntax when minification is enabled:

  /* Original code */
  div {
    transform: translate3d(0, 0, 10px) scale3d(200%, 200%, 1) rotate3d(0, 0, 1, 45deg);
  }
  
  /* Output with "--minify-syntax" */
  div {
    transform: translateZ(10px) scale(2) rotate(45deg);
  }

  The translate3d to translateZ conversion was contributed by @​steambap.

• Support for the case-sensitive flag in CSS attribute selectors (#​1397)

  You can now use the case-sensitive CSS attribute selector flag s such as in [type="a" s] { list-style: lower-alpha; }. Previously doing this caused a warning about unrecognized syntax.

v0.12.9

Compare Source

• Allow this with --define (#​1361)

  You can now override the default value of top-level this with the --define feature. Top-level this defaults to being undefined in ECMAScript modules and exports in CommonJS modules. For example:

  // Original code
  ((obj) => {
    ...
  })(this);
  
  // Output with "--define:this=window"
  ((obj) => {
    ...
  })(window);

  Note that overriding what top-level this is will likely break code that uses it correctly. So this new feature is only useful in certain cases.

• Fix CSS minification issue with !important and duplicate declarations (#​1372)

  Previously CSS with duplicate declarations for the same property where the first one was marked with !important was sometimes minified incorrectly. For example:

  .selector {
    padding: 10px !important;
    padding: 0;
  }

  This was incorrectly minified as .selector{padding:0}. The bug affected three properties: padding, margin, and border-radius. With this release, this code will now be minified as .selector{padding:10px!important;padding:0} instead which means there is no longer a difference between minified and non-minified code in this case.

v0.12.8

Compare Source

• Plugins can now specify sideEffects: false (#​1009)

  The default path resolution behavior in esbuild determines if a given file can be considered side-effect free (in the Webpack-specific sense) by reading the contents of the nearest enclosing package.json file and looking for "sideEffects": false. However, up until now this was impossible to achieve in an esbuild plugin because there was no way of returning this metadata back to esbuild.

  With this release, esbuild plugins can now return sideEffects: false to mark a file as having no side effects. Here's an example:

  esbuild.build({
    entryPoints: ['app.js'],
    bundle: true,
    plugins: [{
      name: 'env-plugin',
      setup(build) {
        build.onResolve({ filter: /^env$/ }, args => ({
          path: args.path,
          namespace: 'some-ns',
          sideEffects: false,
        }))
        build.onLoad({ filter: /.*/, namespace: 'some-ns' }, () => ({
          contents: `export default self.env || (self.env = getEnv())`,
        }))
      },
    }],
  })

  This plugin creates a virtual module that can be generated by importing the string env. However, since the plugin returns sideEffects: false, the generated virtual module will not be included in the bundle if all of the imported values from the module env end up being unused.

  This feature was contributed by @​chriscasola.

• Remove a warning about unsupported source map comments (#​1358)

  This removes a warning that indicated when a source map comment couldn't be supported. Specifically, this happens when you enable source map generation and esbuild encounters a file with a source map comment pointing to an external file but doesn't have enough information to know where to look for that external file (basically when the source file doesn't have an associated directory to use for path resolution). In this case esbuild can't respect the input source map because it cannot be located. The warning was annoying so it has been removed. Source maps still won't work, however.

v0.12.7

Compare Source

• Quote object properties that are modern Unicode identifiers (#​1349)

  In ES6 and above, an identifier is a character sequence starting with a character in the ID_Start Unicode category and followed by zero or more characters in the ID_Continue Unicode category, and these categories must be drawn from Unicode version 5.1 or above.

  But in ES5, an identifier is a character sequence starting with a character in one of the Lu, Ll, Lt, Lm, Lo, Nl Unicode categories and followed by zero or more characters in the Lu, Ll, Lt, Lm, Lo, Nl, Mn, Mc, Nd, Pc Unicode categories, and these categories must be drawn from Unicode version 3.0 or above.

  Previously esbuild always used the ES6+ identifier validation test when deciding whether to use an identifier or a quoted string to encode an object property but with this release, it will use the ES5 validation test instead:

  // Original code
  x.ꓷꓶꓲꓵꓭꓢꓱ = { ꓷꓶꓲꓵꓭꓢꓱ: y };
  
  // Old output
  x.ꓷꓶꓲꓵꓭꓢꓱ = { ꓷꓶꓲꓵꓭꓢꓱ: y };
  
  // New output
  x["ꓷꓶꓲꓵꓭꓢꓱ"] = { "ꓷꓶꓲꓵꓭꓢꓱ": y };

  This approach should ensure maximum compatibility with all JavaScript environments that support ES5 and above. Note that this means minified files containing Unicode properties may be slightly larger than before.

• Ignore tsconfig.json files inside node_modules (#​1355)

  Package authors often publish their tsconfig.json files to npm because of npm's default-include publishing model and because these authors probably don't know about .npmignore files. People trying to use these packages with esbuild have historically complained that esbuild is respecting tsconfig.json in these cases. The assumption is that the package author published these files by accident.

  With this release, esbuild will no longer respect tsconfig.json files when the source file is inside a node_modules folder. Note that tsconfig.json files inside node_modules are still parsed, and extending tsconfig.json files from inside a package is still supported.

• Fix missing --metafile when using --watch (#​1357)

  Due to an oversight, the --metafile setting didn't work when --watch was also specified. This only affected the command-line interface. With this release, the --metafile setting should now work in this case.

• Add a hidden __esModule property to modules in ESM format (#​1338)

  Module namespace objects from ESM files will now have a hidden __esModule property. This improves compatibility with code that has been converted from ESM syntax to CommonJS by Babel or TypeScript. For example:

  // Input TypeScript code
  import x from "y"
  console.log(x)
  
  // Output JavaScript code from the TypeScript compiler
  var __importDefault = (this && this.__importDefault) || function (mod) {
      return (mod && mod.__esModule) ? mod : { "default": mod };
  };
  Object.defineProperty(exports, "__esModule", { value: true });
  const y_1 = __importDefault(require("y"));
  console.log(y_1.default);

  If the object returned by require("y") doesn't have an __esModule property, then y_1 will be the object { "default": require("y") }. If the file "y" is in ESM format and has a default export of, say, the value null, that means y_1 will now be { "default": { "default": null } } and you will need to use y_1.default.default to access the default value. Adding an automatically-generated __esModule property when converting files in ESM format to CommonJS is required to make this code work correctly (i.e. for the value to be accessible via just y_1.default instead).

  With this release, code in ESM format will now have an automatically-generated __esModule property to satisfy this convention. The property is non-enumerable so it shouldn't show up when iterating over the properties of the object. As a result, the export name __esModule is now reserved for use with esbuild. It's now an error to create an export with the name __esModule.

  This fix was contributed by @​lbwa.

v0.12.6

Compare Source

• Improve template literal lowering transformation conformance (#​1327)

  This release contains the following improvements to template literal lowering for environments that don't support tagged template literals natively (such as --target=es5):

  • For tagged template literals, the arrays of strings that are passed to the tag function are now frozen and immutable. They are also now cached so they should now compare identical between multiple template evaluations:

    // Original code
    console.log(tag`\u{10000}`)
    
    // Old output
    console.log(tag(__template(["𐀀"], ["\\u{10000}"])));
    
    // New output
    var _a;
    console.log(tag(_a || (_a = __template(["𐀀"], ["\\u{10000}"]))));

  • For tagged template literals, the generated code size is now smaller in the common case where there are no escape sequences, since in that case there is no distinction between "raw" and "cooked" values:

    // Original code
    console.log(tag`some text without escape sequences`)
    
    // Old output
    console.log(tag(__template(["some text without escape sequences"], ["some text without escape sequences"])));
    
    // New output
    var _a;
    console.log(tag(_a || (_a = __template(["some text without escape sequences"]))));

  • For non-tagged template literals, the generated code now uses chains of .concat() calls instead of string addition:

    // Original code
    console.log(`an ${example} template ${literal}`)
    
    // Old output
    console.log("an " + example + " template " + literal);
    
    // New output
    console.log("an ".concat(example, " template ").concat(literal));

    The old output was incorrect for several reasons including that toString must be called instead of valueOf for objects and that passing a Symbol instance should throw instead of converting the symbol to a string. Using .concat() instead of string addition fixes both of those correctness issues. And you can't use a single .concat() call because side effects must happen inline instead of at the end.

• Only respect target in tsconfig.json when esbuild's target is not configured (#​1332)

  In version 0.12.4, esbuild began respecting the target setting in tsconfig.json. However, sometimes tsconfig.json contains target values that should not be used. With this release, esbuild will now only use the target value in tsconfig.json as the language level when esbuild's target setting is not configured. If esbuild's target setting is configured then the target value in tsconfig.json is now ignored.

• Fix the order of CSS imported from JS (#​1342)

  Importing CSS from JS when bundling causes esbuild to generate a sibling CSS output file next to the resulting JS output file containing the bundled CSS. The order of the imported CSS files in the output was accidentally the inverse order of the order in which the JS files were evaluated. Instead the order of the imported CSS files should match the order in which the JS files were evaluated. This fix was contributed by @​dmitrage.

• Fix an edge case with transforming export default class (#​1346)

  Statements of the form export default class x {} were incorrectly transformed to class x {} var y = x; export {y as default} instead of class x {} export {x as default}. Transforming these statements like this is incorrect in the rare case that the class is later reassigned by name within the same file such as export default class x {} x = null. Here the imported value should be null but was incorrectly the class object instead. This is unlikely to matter in real-world code but it has still been fixed to improve correctness.

---

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.}