Sourced from esbuild's releases.

v0.16.9

• Update to Unicode 15.0.0

  The character tables that determine which characters form valid JavaScript identifiers have been updated from Unicode version 14.0.0 to the newly-released Unicode version 15.0.0. I'm not putting an example in the release notes because all of the new characters will likely just show up as little squares since fonts haven't been updated yet. But you can read https://www.unicode.org/versions/Unicode15.0.0/#Summary for more information about the changes.

• Disallow duplicate lexically-declared names in nested blocks and in strict mode

  In strict mode or in a nested block, it's supposed to be a syntax error to declare two symbols with the same name unless all duplicate entries are either function declarations or all var declarations. However, esbuild was overly permissive and allowed this when duplicate entries were either function declarations or var declarations (even if they were mixed). This check has now been made more restrictive to match the JavaScript specification:

  // JavaScript allows this
  var a
  function a() {}
  {
    var b
    var b
    function c() {}
    function c() {}
  }
  // JavaScript doesn't allow this
  {
  var d
  function d() {}
  }
  

• Add a type declaration for the new empty loader (#2755)

  I forgot to add this in the previous release. It has now been added.

  This fix was contributed by @​fz6m.

• Add support for the v flag in regular expression literals

  People are currently working on adding a v flag to JavaScript regular expresions. You can read more about this flag here: https://v8.dev/features/regexp-v-flag. This release adds support for parsing this flag, so esbuild will now no longer consider regular expression literals with this flag to be a syntax error. If the target is set to something other than esnext, esbuild will transform regular expression literals containing this flag into a new RegExp() constructor call so the resulting code doesn't have a syntax error. This enables you to provide a polyfill for RegExp that implements the v flag to get your code to work at run-time. While esbuild doesn't typically adopt proposals until they're already shipping in a real JavaScript run-time, I'm adding it now because a) esbuild's implementation doesn't need to change as the proposal evolves, b) this isn't really new syntax since regular expression literals already have flags, and c) esbuild's implementation is a trivial pass-through anyway.

• Avoid keeping the name of classes with static name properties

  The --keep-names property attempts to preserve the original value of the name property for functions and classes even when identifiers are renamed by the minifier or to avoid a name collision. This is currently done by generating code to assign a string to the name property on the function or class object. However, this should not be done for classes with a static name property since in that case the explicitly-defined name property overwrites the automatically-generated class name. With this release, esbuild will now no longer attempt to preserve the name property for classes with a static name property.

v0.16.8

• Allow plugins to resolve injected files (#2754)

  Previously paths passed to the inject feature were always interpreted as file system paths. This meant that onResolve plugins would not be run for them and esbuild's default path resolver would always be used. This meant that the inject feature couldn't be used in the browser since the browser doesn't have access to a file system. This release runs paths passed to inject through esbuild's full path resolution pipeline so plugins now have a chance to handle them using onResolve callbacks. This makes it possible to write a plugin that makes esbuild's inject work in the browser.

• Add the empty loader (#1541, #2753)

  The new empty loader tells esbuild to pretend that a file is empty. So for example --loader:.css=empty effectively skips all imports of .css files in JavaScript so that they aren't included in the bundle, since import "./some-empty-file" in JavaScript doesn't bundle anything. You can also use the empty loader to remove asset references in CSS files. For example --loader:.png=empty causes esbuild to replace asset references such as url(image.png) with url() so that they are no longer included in the resulting style sheet.

... (truncated)

Sourced from esbuild's changelog.

0.16.9

• Update to Unicode 15.0.0

  The character tables that determine which characters form valid JavaScript identifiers have been updated from Unicode version 14.0.0 to the newly-released Unicode version 15.0.0. I'm not putting an example in the release notes because all of the new characters will likely just show up as little squares since fonts haven't been updated yet. But you can read https://www.unicode.org/versions/Unicode15.0.0/#Summary for more information about the changes.

• Disallow duplicate lexically-declared names in nested blocks and in strict mode

  In strict mode or in a nested block, it's supposed to be a syntax error to declare two symbols with the same name unless all duplicate entries are either function declarations or all var declarations. However, esbuild was overly permissive and allowed this when duplicate entries were either function declarations or var declarations (even if they were mixed). This check has now been made more restrictive to match the JavaScript specification:

  // JavaScript allows this
  var a
  function a() {}
  {
    var b
    var b
    function c() {}
    function c() {}
  }
  // JavaScript doesn't allow this
  {
  var d
  function d() {}
  }
  

• Add a type declaration for the new empty loader (#2755)

  I forgot to add this in the previous release. It has now been added.

  This fix was contributed by @​fz6m.

• Add support for the v flag in regular expression literals

  People are currently working on adding a v flag to JavaScript regular expresions. You can read more about this flag here: https://v8.dev/features/regexp-v-flag. This release adds support for parsing this flag, so esbuild will now no longer consider regular expression literals with this flag to be a syntax error. If the target is set to something other than esnext, esbuild will transform regular expression literals containing this flag into a new RegExp() constructor call so the resulting code doesn't have a syntax error. This enables you to provide a polyfill for RegExp that implements the v flag to get your code to work at run-time. While esbuild doesn't typically adopt proposals until they're already shipping in a real JavaScript run-time, I'm adding it now because a) esbuild's implementation doesn't need to change as the proposal evolves, b) this isn't really new syntax since regular expression literals already have flags, and c) esbuild's implementation is a trivial pass-through anyway.

• Avoid keeping the name of classes with static name properties

  The --keep-names property attempts to preserve the original value of the name property for functions and classes even when identifiers are renamed by the minifier or to avoid a name collision. This is currently done by generating code to assign a string to the name property on the function or class object. However, this should not be done for classes with a static name property since in that case the explicitly-defined name property overwrites the automatically-generated class name. With this release, esbuild will now no longer attempt to preserve the name property for classes with a static name property.

0.16.8

• Allow plugins to resolve injected files (#2754)

  Previously paths passed to the inject feature were always interpreted as file system paths. This meant that onResolve plugins would not be run for them and esbuild's default path resolver would always be used. This meant that the inject feature couldn't be used in the browser since the browser doesn't have access to a file system. This release runs paths passed to inject through esbuild's full path resolution pipeline so plugins now have a chance to handle them using onResolve callbacks. This makes it possible to write a plugin that makes esbuild's inject work in the browser.

• Add the empty loader (#1541, #2753)

... (truncated)

• 29ae56a publish 0.16.9 to npm
• d2aa4eb fix lexically-declared names in strict mode
• 0c15c1e implement test262 json module loading
• 55e2738 fix js tests for node v19+
• 88ef1de update source-map library for node v19
• 7c249a9 avoid keep names of class static name properties
• ff1681e more test262 adjustments
• 5ee1dbf attempt to run test262 tests in a harness
• 94fcbf6 rewrite the test262 script
• b5ec405 support the v regular expression literal flag
• Additional commits viewable in compare view

You can trigger Dependabot actions by commenting on this PR:

• @dependabot rebase will rebase this PR
• @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
• @dependabot merge will merge this PR after your CI passes on it
• @dependabot squash and merge will squash and merge this PR after your CI passes on it
• @dependabot cancel merge will cancel a previously requested merge and block automerging
• @dependabot reopen will reopen this PR if it is closed
• @dependabot close will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually
• @dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)

Sourced from esbuild's releases.

v0.16.4

• Fix binary downloads from the @esbuild/ scope for Deno (#2729)

  Version 0.16.0 of esbuild moved esbuild's binary executables into npm packages under the @esbuild/ scope, which accidentally broke the binary downloader script for Deno. This release fixes this script so it should now be possible to use esbuild version 0.16.4+ with Deno.

v0.16.3

• Fix a hang with the JS API in certain cases (#2727)

  A change that was made in version 0.15.13 accidentally introduced a case when using esbuild's JS API could cause the node process to fail to exit. The change broke esbuild's watchdog timer, which detects if the parent process no longer exists and then automatically exits esbuild. This hang happened when you ran node as a child process with the stderr stream set to pipe instead of inherit, in the child process you call esbuild's JS API and pass incremental: true but do not call dispose() on the returned rebuild object, and then call process.exit(). In that case the parent node process was still waiting for the esbuild process that was created by the child node process to exit. The change made in version 0.15.13 was trying to avoid using Go's sync.WaitGroup API incorrectly because the API is not thread-safe. Instead of doing this, I have now reverted that change and implemented a thread-safe version of the sync.WaitGroup API for esbuild to use instead.

v0.16.2

• Fix process.env.NODE_ENV substitution when transforming (#2718)

  Version 0.16.0 introduced an unintentional regression that caused process.env.NODE_ENV to be automatically substituted with either "development" or "production" when using esbuild's transform API. This substitution is a necessary feature of esbuild's build API because the React framework crashes when you bundle it without doing this. But the transform API is typically used as part of a larger build pipeline so the benefit of esbuild doing this automatically is not as clear, and esbuild previously didn't do this.

  However, version 0.16.0 switched the default value of the platform setting for the transform API from neutral to browser, both to align it with esbuild's documentation (which says browser is the default value) and because escaping the </script> character sequence is now tied to the browser platform (see the release notes for version 0.16.0 for details). That accidentally enabled automatic substitution of process.env.NODE_ENV because esbuild always did that for code meant for the browser. To fix this regression, esbuild will now only automatically substitute process.env.NODE_ENV when using the build API.

• Prevent define from substituting constants into assignment position (#2719)

  The define feature lets you replace certain expressions with constants. For example, you could use it to replace references to the global property reference window.DEBUG with false at compile time, which can then potentially help esbuild remove unused code from your bundle. It's similar to DefinePlugin in Webpack.

  However, if you write code such as window.DEBUG = true and then defined window.DEBUG to false, esbuild previously generated the output false = true which is a syntax error in JavaScript. This behavior is not typically a problem because it doesn't make sense to substitute window.DEBUG with a constant if its value changes at run-time (Webpack's DefinePlugin also generates false = true in this case). But it can be alarming to have esbuild generate code with a syntax error.

  So with this release, esbuild will no longer substitute define constants into assignment position to avoid generating code with a syntax error. Instead esbuild will generate a warning, which currently looks like this:

  ▲ [WARNING] Suspicious assignment to defined constant "window.DEBUG" [assign-to-define]
  example.js:1:0:
    1 │ window.DEBUG = true
      ╵ ~~~~~~~~~~~~
  
  The expression "window.DEBUG" has been configured to be replaced with a constant using the
  "define" feature. If this expression is supposed to be a compile-time constant, then it doesn't
  make sense to assign to it here. Or if this expression is supposed to change at run-time, this
  "define" substitution should be removed.
  

• Fix a regression with npm install --no-optional (#2720)

  Normally when you install esbuild with npm install, npm itself is the tool that downloads the correct binary executable for the current platform. This happens because of how esbuild's primary package uses npm's optionalDependencies feature. However, if you deliberately disable this with npm install --no-optional then esbuild's install script will attempt to repair the installation by manually downloading and extracting the binary executable from the package that was supposed to be installed.

  The change in version 0.16.0 to move esbuild's nested packages into the @esbuild/ scope unintentionally broke this logic because of how npm's URL structure is different for scoped packages vs. normal packages. It was actually already broken for a few platforms earlier because esbuild already had packages for some platforms in the @esbuild/ scope, but I didn't discover this then because esbuild's integration tests aren't run on all platforms. Anyway, this release contains some changes to the install script that should hopefully get this scenario working again.

v0.16.1

This is a hotfix for the previous release.

• Re-allow importing JSON with the copy loader using an import assertion

  The previous release made it so when assert { type: 'json' } is present on an import statement, esbuild validated that the json loader was used. This is what an import assertion is supposed to do. However, I forgot about the relatively new copy loader, which sort of behaves as if the import path was marked as external (and thus not loaded at all) except that the file is copied to the output directory and the import path is rewritten to point to the copy. In this case whatever JavaScript runtime ends up running the code is the one to evaluate the import assertion. So esbuild should really allow this case as well. With this release, esbuild now allows both the json and copy loaders when an assert { type: 'json' } import assertion is present.

... (truncated)

Sourced from esbuild's changelog.

0.16.4

• Fix binary downloads from the @esbuild/ scope for Deno (#2729)

  Version 0.16.0 of esbuild moved esbuild's binary executables into npm packages under the @esbuild/ scope, which accidentally broke the binary downloader script for Deno. This release fixes this script so it should now be possible to use esbuild version 0.16.4+ with Deno.

0.16.3

• Fix a hang with the JS API in certain cases (#2727)

  A change that was made in version 0.15.13 accidentally introduced a case when using esbuild's JS API could cause the node process to fail to exit. The change broke esbuild's watchdog timer, which detects if the parent process no longer exists and then automatically exits esbuild. This hang happened when you ran node as a child process with the stderr stream set to pipe instead of inherit, in the child process you call esbuild's JS API and pass incremental: true but do not call dispose() on the returned rebuild object, and then call process.exit(). In that case the parent node process was still waiting for the esbuild process that was created by the child node process to exit. The change made in version 0.15.13 was trying to avoid using Go's sync.WaitGroup API incorrectly because the API is not thread-safe. Instead of doing this, I have now reverted that change and implemented a thread-safe version of the sync.WaitGroup API for esbuild to use instead.

0.16.2

• Fix process.env.NODE_ENV substitution when transforming (#2718)

  Version 0.16.0 introduced an unintentional regression that caused process.env.NODE_ENV to be automatically substituted with either "development" or "production" when using esbuild's transform API. This substitution is a necessary feature of esbuild's build API because the React framework crashes when you bundle it without doing this. But the transform API is typically used as part of a larger build pipeline so the benefit of esbuild doing this automatically is not as clear, and esbuild previously didn't do this.

  However, version 0.16.0 switched the default value of the platform setting for the transform API from neutral to browser, both to align it with esbuild's documentation (which says browser is the default value) and because escaping the </script> character sequence is now tied to the browser platform (see the release notes for version 0.16.0 for details). That accidentally enabled automatic substitution of process.env.NODE_ENV because esbuild always did that for code meant for the browser. To fix this regression, esbuild will now only automatically substitute process.env.NODE_ENV when using the build API.

• Prevent define from substituting constants into assignment position (#2719)

  The define feature lets you replace certain expressions with constants. For example, you could use it to replace references to the global property reference window.DEBUG with false at compile time, which can then potentially help esbuild remove unused code from your bundle. It's similar to DefinePlugin in Webpack.

  However, if you write code such as window.DEBUG = true and then defined window.DEBUG to false, esbuild previously generated the output false = true which is a syntax error in JavaScript. This behavior is not typically a problem because it doesn't make sense to substitute window.DEBUG with a constant if its value changes at run-time (Webpack's DefinePlugin also generates false = true in this case). But it can be alarming to have esbuild generate code with a syntax error.

  So with this release, esbuild will no longer substitute define constants into assignment position to avoid generating code with a syntax error. Instead esbuild will generate a warning, which currently looks like this:

  ▲ [WARNING] Suspicious assignment to defined constant "window.DEBUG" [assign-to-define]
  example.js:1:0:
    1 │ window.DEBUG = true
      ╵ ~~~~~~~~~~~~
  
  The expression "window.DEBUG" has been configured to be replaced with a constant using the
  "define" feature. If this expression is supposed to be a compile-time constant, then it doesn't
  make sense to assign to it here. Or if this expression is supposed to change at run-time, this
  "define" substitution should be removed.
  

• Fix a regression with npm install --no-optional (#2720)

  Normally when you install esbuild with npm install, npm itself is the tool that downloads the correct binary executable for the current platform. This happens because of how esbuild's primary package uses npm's optionalDependencies feature. However, if you deliberately disable this with npm install --no-optional then esbuild's install script will attempt to repair the installation by manually downloading and extracting the binary executable from the package that was supposed to be installed.

  The change in version 0.16.0 to move esbuild's nested packages into the @esbuild/ scope unintentionally broke this logic because of how npm's URL structure is different for scoped packages vs. normal packages. It was actually already broken for a few platforms earlier because esbuild already had packages for some platforms in the @esbuild/ scope, but I didn't discover this then because esbuild's integration tests aren't run on all platforms. Anyway, this release contains some changes to the install script that should hopefully get this scenario working again.

0.16.1

This is a hotfix for the previous release.

... (truncated)

• 643af8e publish 0.16.4 to npm
• 1fb0ee9 fix #2729: esbuild should now work with deno again
• b3231a8 update go 1.19.3 => 1.19.4
• 7076c56 enable running end-to-end tests on demand
• a909586 add an end-to-end test for deno (#2729)
• 8ef19fe publish 0.16.3 to npm
• 8648239 fix #2727: avoid sync.WaitGroup to fix hang
• 2ec1f5b add a timeout for yarn pnp tests
• 0829d74 publish 0.16.2 to npm
• 7b45a3b fix #2718: transform keeps process.env.NODE_ENV
• Additional commits viewable in compare view

You can trigger Dependabot actions by commenting on this PR:

• @dependabot rebase will rebase this PR
• @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
• @dependabot merge will merge this PR after your CI passes on it
• @dependabot squash and merge will squash and merge this PR after your CI passes on it
• @dependabot cancel merge will cancel a previously requested merge and block automerging
• @dependabot reopen will reopen this PR if it is closed
• @dependabot close will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually
• @dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)

Sourced from esbuild's releases.

v0.15.18

• Performance improvements for both JS and CSS

  This release brings noticeable performance improvements for JS parsing and for CSS parsing and printing. Here's an example benchmark for using esbuild to pretty-print a single large minified CSS file and JS file:

  Test case	Previous release	This release
  4.8mb CSS file	19ms	11ms (1.7x faster)
  5.8mb JS file	36ms	32ms (1.1x faster)

  The performance improvements were very straightforward:

  • Identifiers were being scanned using a generic character advancement function instead of using custom inline code. Advancing past each character involved UTF-8 decoding as well as updating multiple member variables. This was sped up using loop that skips UTF-8 decoding entirely and that only updates member variables once at the end. This is faster because identifiers are plain ASCII in the vast majority of cases, so Unicode decoding is almost always unnecessary.

  • CSS identifiers and CSS strings were still being printed one character at a time. Apparently I forgot to move this part of esbuild's CSS infrastructure beyond the proof-of-concept stage. These were both very obvious in the profiler, so I think maybe I have just never profiled esbuild's CSS printing before?

  • There was unnecessary work being done that was related to source maps when source map output was disabled. I likely haven't observed this before because esbuild's benchmarks always have source maps enabled. This work is now disabled when it's not going to be used.

  I definitely should have caught these performance issues earlier. Better late than never I suppose.

v0.15.17

• Search for missing source map code on the file system (#2711)

  Source maps are JSON files that map from compiled code back to the original code. They provide the original source code using two arrays: sources (required) and sourcesContent (optional). When bundling is enabled, esbuild is able to bundle code with source maps that was compiled by other tools (e.g. with Webpack) and emit source maps that map all the way back to the original code (e.g. before Webpack compiled it).

  Previously if the input source maps omitted the optional sourcesContent array, esbuild would use null for the source content in the source map that it generates (since the source content isn't available). However, sometimes the original source code is actually still present on the file system. With this release, esbuild will now try to find the original source code using the path in the sources array and will use that instead of null if it was found.

• Fix parsing bug with TypeScript infer and extends (#2712)

  This release fixes a bug where esbuild incorrectly failed to parse valid TypeScript code that nests extends inside infer inside extends, such as in the example below:

  type A<T> = {};
  type B = {} extends infer T extends {} ? A<T> : never;
  

  TypeScript code that does this should now be parsed correctly.

• Use WebAssembly.instantiateStreaming if available (#1036, #1900)

  Currently the WebAssembly version of esbuild uses fetch to download esbuild.wasm and then WebAssembly.instantiate to compile it. There is a newer API called WebAssembly.instantiateStreaming that both downloads and compiles at the same time, which can be a performance improvement if both downloading and compiling are slow. With this release, esbuild now attempts to use WebAssembly.instantiateStreaming and falls back to the original approach if that fails.

  The implementation for this builds on a PR by @​lbwa.

• Preserve Webpack comments inside constructor calls (#2439)

  This improves the use of esbuild as a faster TypeScript-to-JavaScript frontend for Webpack, which has special magic comments inside new Worker() expressions that affect Webpack's behavior.

v0.15.16

• Add a package alias feature (#2191)

... (truncated)

Sourced from esbuild's changelog.

0.15.18

• Performance improvements for both JS and CSS

  This release brings noticeable performance improvements for JS parsing and for CSS parsing and printing. Here's an example benchmark for using esbuild to pretty-print a single large minified CSS file and JS file:

  Test case	Previous release	This release
  4.8mb CSS file	19ms	11ms (1.7x faster)
  5.8mb JS file	36ms	32ms (1.1x faster)

  The performance improvements were very straightforward:

  • Identifiers were being scanned using a generic character advancement function instead of using custom inline code. Advancing past each character involved UTF-8 decoding as well as updating multiple member variables. This was sped up using loop that skips UTF-8 decoding entirely and that only updates member variables once at the end. This is faster because identifiers are plain ASCII in the vast majority of cases, so Unicode decoding is almost always unnecessary.

  • CSS identifiers and CSS strings were still being printed one character at a time. Apparently I forgot to move this part of esbuild's CSS infrastructure beyond the proof-of-concept stage. These were both very obvious in the profiler, so I think maybe I have just never profiled esbuild's CSS printing before?

  • There was unnecessary work being done that was related to source maps when source map output was disabled. I likely haven't observed this before because esbuild's benchmarks always have source maps enabled. This work is now disabled when it's not going to be used.

  I definitely should have caught these performance issues earlier. Better late than never I suppose.

0.15.17

• Search for missing source map code on the file system (#2711)

  Source maps are JSON files that map from compiled code back to the original code. They provide the original source code using two arrays: sources (required) and sourcesContent (optional). When bundling is enabled, esbuild is able to bundle code with source maps that was compiled by other tools (e.g. with Webpack) and emit source maps that map all the way back to the original code (e.g. before Webpack compiled it).

  Previously if the input source maps omitted the optional sourcesContent array, esbuild would use null for the source content in the source map that it generates (since the source content isn't available). However, sometimes the original source code is actually still present on the file system. With this release, esbuild will now try to find the original source code using the path in the sources array and will use that instead of null if it was found.

• Fix parsing bug with TypeScript infer and extends (#2712)

  This release fixes a bug where esbuild incorrectly failed to parse valid TypeScript code that nests extends inside infer inside extends, such as in the example below:

  type A<T> = {};
  type B = {} extends infer T extends {} ? A<T> : never;
  

  TypeScript code that does this should now be parsed correctly.

• Use WebAssembly.instantiateStreaming if available (#1036, #1900)

  Currently the WebAssembly version of esbuild uses fetch to download esbuild.wasm and then WebAssembly.instantiate to compile it. There is a newer API called WebAssembly.instantiateStreaming that both downloads and compiles at the same time, which can be a performance improvement if both downloading and compiling are slow. With this release, esbuild now attempts to use WebAssembly.instantiateStreaming and falls back to the original approach if that fails.

  The implementation for this builds on a PR by @​lbwa.

• Preserve Webpack comments inside constructor calls (#2439)

  This improves the use of esbuild as a faster TypeScript-to-JavaScript frontend for Webpack, which has special magic comments inside new Worker() expressions that affect Webpack's behavior.

... (truncated)

• 2953831 publish 0.15.18 to npm
• a3ba2b2 perf release notes
• f0d8fdd oops: skip source maps for improved performance
• e49e093 css: optimize printing quoted unescaped strings
• a193324 css: improve identifier printing performance
• 83b5580 css: pretty-print test failures
• 2b8883c css: improve lexer identifier parsing performance
• f6f8b27 js: improve lexer identifier parsing performance
• decf208 restrict gc disable to not serve or watch mode
• 2030df1 don't disable the gc with multiple entry points
• Additional commits viewable in compare view

You can trigger Dependabot actions by commenting on this PR:

• @dependabot rebase will rebase this PR
• @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
• @dependabot merge will merge this PR after your CI passes on it
• @dependabot squash and merge will squash and merge this PR after your CI passes on it
• @dependabot cancel merge will cancel a previously requested merge and block automerging
• @dependabot reopen will reopen this PR if it is closed
• @dependabot close will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually
• @dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)

Sourced from esbuild's releases.

v0.15.16

• Add a package alias feature (#2191)

  With this release, you can now easily substitute one package for another at build time with the new alias feature. For example, --alias:oldpkg=newpkg replaces all imports of oldpkg with newpkg. One use case for this is easily replacing a node-only package with a browser-friendly package in 3rd-party code that you don't control. These new substitutions happen first before all of esbuild's existing path resolution logic.

  Note that when an import path is substituted using an alias, the resulting import path is resolved in the working directory instead of in the directory containing the source file with the import path. If needed, the working directory can be set with the cd command when using the CLI or with the absWorkingDir setting when using the JS or Go APIs.

• Fix crash when pretty-printing minified JSX with object spread of object literal with computed property (#2697)

  JSX elements are translated to JavaScript function calls and JSX element attributes are translated to properties on a JavaScript object literal. These properties are always either strings (e.g. in <x y />, y is a string) or an object spread (e.g. in <x {...y} />, y is an object spread) because JSX doesn't provide syntax for directly passing a computed property as a JSX attribute. However, esbuild's minifier has a rule that tries to inline object spread with an inline object literal in JavaScript. For example, x = { ...{ y } } is minified to x={y} when minification is enabled. This means that there is a way to generate a non-string non-spread JSX attribute in esbuild's internal representation. One example is with <x {...{ [y]: z }} />. When minification is enabled, esbuild's internal representation of this is something like <x [y]={z} /> due to object spread inlining, which is not valid JSX syntax. If this internal representation is then pretty-printed as JSX using --minify --jsx=preserve, esbuild previously crashed when trying to print this invalid syntax. With this release, esbuild will now print <x {...{[y]:z}}/> in this scenario instead of crashing.

v0.15.15

• Remove duplicate CSS rules across files (#2688)

  When two or more CSS rules are exactly the same (even if they are not adjacent), all but the last one can safely be removed:

  /* Before */
  a { color: red; }
  span { font-weight: bold; }
  a { color: red; }
  /* After */
  span { font-weight: bold; }
  a { color: red; }
  

  Previously esbuild only did this transformation within a single source file. But with this release, esbuild will now do this transformation across source files, which may lead to smaller CSS output if the same rules are repeated across multiple CSS source files in the same bundle. This transformation is only enabled when minifying (specifically when syntax minification is enabled).

• Add deno as a valid value for target (#2686)

  The target setting in esbuild allows you to enable or disable JavaScript syntax features for a given version of a set of target JavaScript VMs. Previously Deno was not one of the JavaScript VMs that esbuild supported with target, but it will now be supported starting from this release. For example, versions of Deno older than v1.2 don't support the new ||= operator, so adding e.g. --target=deno1.0 to esbuild now lets you tell esbuild to transpile ||= to older JavaScript.

• Fix the esbuild-wasm package in Node v19 (#2683)

  A recent change to Node v19 added a non-writable crypto property to the global object: nodejs/node#44897. This conflicts with Go's WebAssembly shim code, which overwrites the global crypto property. As a result, all Go-based WebAssembly code that uses the built-in shim (including esbuild) is now broken on Node v19. This release of esbuild fixes the issue by reconfiguring the global crypto property to be writable before invoking Go's WebAssembly shim code.

• Fix CSS dimension printing exponent confusion edge case (#2677)

  In CSS, a dimension token has a numeric "value" part and an identifier "unit" part. For example, the dimension token 32px has a value of 32 and a unit of px. The unit can be any valid CSS identifier. The value can be any number in floating-point format including an optional exponent (e.g. -3.14e-0 has an exponent of e-0). The full details of this syntax are here: https://www.w3.org/TR/css-syntax-3/.

  To maintain the integrity of the dimension token through the printing process, esbuild must handle the edge case where the unit looks like an exponent. One such case is the dimension 1e\32 which has the value 1 and the unit e2. It would be bad if this dimension token was printed such that a CSS parser would parse it as a number token with the value 1e2 instead of a dimension token. The way esbuild currently does this is to escape the leading e in the dimension unit, so esbuild would parse 1e\32 but print 1\65 2 (both 1e\32 and 1\65 2 represent a dimension token with a value of 1 and a unit of e2).

  However, there is an even narrower edge case regarding this edge case. If the value part of the dimension token itself has an e, then it's not necessary to escape the e in the dimension unit because a CSS parser won't confuse the unit with the exponent even though it looks like one (since a number can only have at most one exponent). This came up because the grammar for the CSS unicode-range property uses a hack that lets you specify a hexadecimal range without quotes even though CSS has no token for a hexadecimal range. The hack is to allow the hexadecimal range to be parsed as a dimension token and optionally also a number token. Here is the grammar for unicode-range:

  unicode-range =
    <urange>#
  <urange> =
  

... (truncated)

Sourced from esbuild's changelog.

0.15.16

• Add a package alias feature (#2191)

  With this release, you can now easily substitute one package for another at build time with the new alias feature. For example, --alias:oldpkg=newpkg replaces all imports of oldpkg with newpkg. One use case for this is easily replacing a node-only package with a browser-friendly package in 3rd-party code that you don't control. These new substitutions happen first before all of esbuild's existing path resolution logic.

  Note that when an import path is substituted using an alias, the resulting import path is resolved in the working directory instead of in the directory containing the source file with the import path. If needed, the working directory can be set with the cd command when using the CLI or with the absWorkingDir setting when using the JS or Go APIs.

• Fix crash when pretty-printing minified JSX with object spread of object literal with computed property (#2697)

  JSX elements are translated to JavaScript function calls and JSX element attributes are translated to properties on a JavaScript object literal. These properties are always either strings (e.g. in <x y />, y is a string) or an object spread (e.g. in <x {...y} />, y is an object spread) because JSX doesn't provide syntax for directly passing a computed property as a JSX attribute. However, esbuild's minifier has a rule that tries to inline object spread with an inline object literal in JavaScript. For example, x = { ...{ y } } is minified to x={y} when minification is enabled. This means that there is a way to generate a non-string non-spread JSX attribute in esbuild's internal representation. One example is with <x {...{ [y]: z }} />. When minification is enabled, esbuild's internal representation of this is something like <x [y]={z} /> due to object spread inlining, which is not valid JSX syntax. If this internal representation is then pretty-printed as JSX using --minify --jsx=preserve, esbuild previously crashed when trying to print this invalid syntax. With this release, esbuild will now print <x {...{[y]:z}}/> in this scenario instead of crashing.

0.15.15

• Remove duplicate CSS rules across files (#2688)

  When two or more CSS rules are exactly the same (even if they are not adjacent), all but the last one can safely be removed:

  /* Before */
  a { color: red; }
  span { font-weight: bold; }
  a { color: red; }
  /* After */
  span { font-weight: bold; }
  a { color: red; }
  

  Previously esbuild only did this transformation within a single source file. But with this release, esbuild will now do this transformation across source files, which may lead to smaller CSS output if the same rules are repeated across multiple CSS source files in the same bundle. This transformation is only enabled when minifying (specifically when syntax minification is enabled).

• Add deno as a valid value for target (#2686)

  The target setting in esbuild allows you to enable or disable JavaScript syntax features for a given version of a set of target JavaScript VMs. Previously Deno was not one of the JavaScript VMs that esbuild supported with target, but it will now be supported starting from this release. For example, versions of Deno older than v1.2 don't support the new ||= operator, so adding e.g. --target=deno1.0 to esbuild now lets you tell esbuild to transpile ||= to older JavaScript.

• Fix the esbuild-wasm package in Node v19 (#2683)

  A recent change to Node v19 added a non-writable crypto property to the global object: nodejs/node#44897. This conflicts with Go's WebAssembly shim code, which overwrites the global crypto property. As a result, all Go-based WebAssembly code that uses the built-in shim (including esbuild) is now broken on Node v19. This release of esbuild fixes the issue by reconfiguring the global crypto property to be writable before invoking Go's WebAssembly shim code.

• Fix CSS dimension printing exponent confusion edge case (#2677)

  In CSS, a dimension token has a numeric "value" part and an identifier "unit" part. For example, the dimension token 32px has a value of 32 and a unit of px. The unit can be any valid CSS identifier. The value can be any number in floating-point format including an optional exponent (e.g. -3.14e-0 has an exponent of e-0). The full details of this syntax are here: https://www.w3.org/TR/css-syntax-3/.

  To maintain the integrity of the dimension token through the printing process, esbuild must handle the edge case where the unit looks like an exponent. One such case is the dimension 1e\32 which has the value 1 and the unit e2. It would be bad if this dimension token was printed such that a CSS parser would parse it as a number token with the value 1e2 instead of a dimension token. The way esbuild currently does this is to escape the leading e in the dimension unit, so esbuild would parse 1e\32 but print 1\65 2 (both 1e\32 and 1\65 2 represent a dimension token with a value of 1 and a unit of e2).

  However, there is an even narrower edge case regarding this edge case. If the value part of the dimension token itself has an e, then it's not necessary to escape the e in the dimension unit because a CSS parser won't confuse the unit with the exponent even though it looks like one (since a number can only have at most one exponent). This came up because the grammar for the CSS unicode-range property uses a hack that lets you specify a hexadecimal range without quotes even though CSS has no token for a hexadecimal range. The hack is to allow the hexadecimal range to be parsed as a dimension token and optionally also a number token. Here is the grammar for unicode-range:

  unicode-range =
    <urange>#
  

... (truncated)

• 50ae05b publish 0.15.16 to npm
• d8d7362 alias: more tests, allow relative substitutions
• a7eb789 fix #2191: add a path alias feature
• 4e9f9c1 fix indentation for some tests
• 89e4520 fix #2697: jsx + spread + computed property crash
• ef348a3 jsx: pretty-print single-line JSX elements
• 478062d publish 0.15.15 to npm
• e7ad5fb remove duplicate css rules across files (#2688)
• 6664172 test duplicate rule merging after bundling
• a73c4e9 css: merge adjacent selectors forward not backward
• Additional commits viewable in compare view

You can trigger Dependabot actions by commenting on this PR:

• @dependabot rebase will rebase this PR
• @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
• @dependabot merge will merge this PR after your CI passes on it
• @dependabot squash and merge will squash and merge this PR after your CI passes on it
• @dependabot cancel merge will cancel a previously requested merge and block automerging
• @dependabot reopen will reopen this PR if it is closed
• @dependabot close will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually
• @dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)

Sourced from esbuild's releases.

v0.15.13

• Add support for the TypeScript 4.9 satisfies operator (#2509)

  TypeScript 4.9 introduces a new operator called satisfies that lets you check that a given value satisfies a less specific type without casting it to that less specific type and without generating any additional code at run-time. It looks like this:

  const value = { foo: 1, bar: false } satisfies Record<string, number | boolean>
  console.log(value.foo.toFixed(1)) // TypeScript knows that "foo" is a number here
  

  Before this existed, you could use a cast with as to check that a value satisfies a less specific type, but that removes any additional knowledge that TypeScript has about that specific value:

  const value = { foo: 1, bar: false } as Record<string, number | boolean>
  console.log(value.foo.toFixed(1)) // TypeScript no longer knows that "foo" is a number
  

  You can read more about this feature in TypeScript's blog post for 4.9 as well as the associated TypeScript issue for this feature.

  This feature was implemented in esbuild by @​magic-akari.

• Fix watch mode constantly rebuilding if the parent directory is inaccessible (#2640)

  Android is unusual in that it has an inaccessible directory in the path to the root, which esbuild was not originally built to handle. To handle cases like this, the path resolution layer in esbuild has a hack where it treats inaccessible directories as empty. However, esbuild's watch implementation currently triggers a rebuild if a directory previously encountered an error but the directory now exists. The assumption is that the previous error was caused by the directory not existing. Although that's usually the case, it's not the case for this particular parent directory on Android. Instead the error is that the directory previously existed but was inaccessible.

  This discrepancy between esbuild's path resolution layer and its watch mode was causing watch mode to rebuild continuously on Android. With this release, esbuild's watch mode instead checks for an error status change in the readdir file system call, so watch mode should no longer rebuild continuously on Android.

• Apply a fix for a rare deadlock with the JavaScript API (#1842, #2485)

  There have been reports of esbuild sometimes exiting with an "all goroutines are asleep" deadlock message from the Go language runtime. This issue hasn't made much progress until recently, where a possible cause was discovered (thanks to @​jfirebaugh for the investigation). This release contains a possible fix for that possible cause, so this deadlock may have been fixed. The fix cannot be easily verified because the deadlock is non-deterministic and rare. If this was indeed the cause, then this issue only affected the JavaScript API in situations where esbuild was already in the process of exiting.

  In detail: The underlying cause is that Go's sync.WaitGroup API for waiting for a set of goroutines to finish is not fully thread-safe. Specifically it's not safe to call Add() concurrently with Wait() when the wait group counter is zero due to a data race. This situation could come up with esbuild's JavaScript API when the host JavaScript process closes the child process's stdin and the child process (with no active tasks) calls Wait() to check that there are no active tasks, at the same time as esbuild's watchdog timer calls Add() to add an active task (that pings the host to see if it's still there). The fix in this release is to avoid calling Add() once we learn that stdin has been closed but before we call Wait().

v0.15.12

• Fix minifier correctness bug with single-use substitutions (#2619)

  When minification is enabled, esbuild will attempt to eliminate variables that are only used once in certain cases. For example, esbuild minifies this code:

  function getEmailForUser(name) {
    let users = db.table('users');
    let user = users.find({ name });
    let email = user?.get('email');
    return email;
  }
  

  into this code:

... (truncated)

Sourced from esbuild's changelog.

0.15.13

• Add support for the TypeScript 4.9 satisfies operator (#2509)

  TypeScript 4.9 introduces a new operator called satisfies that lets you check that a given value satisfies a less specific type without casting it to that less specific type and without generating any additional code at run-time. It looks like this:

  const value = { foo: 1, bar: false } satisfies Record<string, number | boolean>
  console.log(value.foo.toFixed(1)) // TypeScript knows that "foo" is a number here
  

  Before this existed, you could use a cast with as to check that a value satisfies a less specific type, but that removes any additional knowledge that TypeScript has about that specific value:

  const value = { foo: 1, bar: false } as Record<string, number | boolean>
  console.log(value.foo.toFixed(1)) // TypeScript no longer knows that "foo" is a number
  

  You can read more about this feature in TypeScript's blog post for 4.9 as well as the associated TypeScript issue for this feature.

  This feature was implemented in esbuild by @​magic-akari.

• Fix watch mode constantly rebuilding if the parent directory is inaccessible (#2640)

  Android is unusual in that it has an inaccessible directory in the path to the root, which esbuild was not originally built to handle. To handle cases like this, the path resolution layer in esbuild has a hack where it treats inaccessible directories as empty. However, esbuild's watch implementation currently triggers a rebuild if a directory previously encountered an error but the directory now exists. The assumption is that the previous error was caused by the directory not existing. Although that's usually the case, it's not the case for this particular parent directory on Android. Instead the error is that the directory previously existed but was inaccessible.

  This discrepancy between esbuild's path resolution layer and its watch mode was causing watch mode to rebuild continuously on Android. With this release, esbuild's watch mode instead checks for an error status change in the readdir file system call, so watch mode should no longer rebuild continuously on Android.

• Apply a fix for a rare deadlock with the JavaScript API (#1842, #2485)

  There have been reports of esbuild sometimes exiting with an "all goroutines are asleep" deadlock message from the Go language runtime. This issue hasn't made much progress until recently, where a possible cause was discovered (thanks to @​jfirebaugh for the investigation). This release contains a possible fix for that possible cause, so this deadlock may have been fixed. The fix cannot be easily verified because the deadlock is non-deterministic and rare. If this was indeed the cause, then this issue only affected the JavaScript API in situations where esbuild was already in the process of exiting.

  In detail: The underlying cause is that Go's sync.WaitGroup API for waiting for a set of goroutines to finish is not fully thread-safe. Specifically it's not safe to call Add() concurrently with Wait() when the wait group counter is zero due to a data race. This situation could come up with esbuild's JavaScript API when the host JavaScript process closes the child process's stdin and the child process (with no active tasks) calls Wait() to check that there are no active tasks, at the same time as esbuild's watchdog timer calls Add() to add an active task (that pings the host to see if it's still there). The fix in this release is to avoid calling Add() once we learn that stdin has been closed but before we call Wait().

0.15.12

• Fix minifier correctness bug with single-use substitutions (#2619)

  When minification is enabled, esbuild will attempt to eliminate variables that are only used once in certain cases. For example, esbuild minifies this code:

  function getEmailForUser(name) {
    let users = db.table('users');
    let user = users.find({ name });
    let email = user?.get('email');
    return email;
  }
  

  into this code:

... (truncated)

• ba47710 publish 0.15.13 to npm
• 679548f small code simplification
• 78d6194 attempted fix for #2485: Add and Wait safety
• 4f9694b fix a typo
• 8d0c2b9 update go 1.19.2 => 1.19.3
• 8c2fdc2 support TypeScript satisfies (#2509)
• 97d6dba fix #2640: watch mode checks readdir, not stat
• 223e6ea publish 0.15.12 to npm
• ccc8e8b fix #2619: bug with single-use substitutions
• 4608721 ci: update github actions (#2612)
• Additional commits viewable in compare view

You can trigger Dependabot actions by commenting on this PR:

• @dependabot rebase will rebase this PR
• @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
• @dependabot merge will merge this PR after your CI passes on it
• @dependabot squash and merge will squash and merge this PR after your CI passes on it
• @dependabot cancel merge will cancel a previously requested merge and block automerging
• @dependabot reopen will reopen this PR if it is closed
• @dependabot close will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually
• @dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)

Sourced from esbuild's releases.

v0.15.12

• Fix minifier correctness bug with single-use substitutions (#2619)

  When minification is enabled, esbuild will attempt to eliminate variables that are only used once in certain cases. For example, esbuild minifies this code:

  function getEmailForUser(name) {
    let users = db.table('users');
    let user = users.find({ name });
    let email = user?.get('email');
    return email;
  }
  

  into this code:

  function getEmailForUser(e){return db.table("users").find({name:e})?.get("email")}
  

  However, this transformation had a bug where esbuild did not correctly consider the "read" part of binary read-modify-write assignment operators. For example, it's incorrect to minify the following code into bar += fn() because the call to fn() might modify bar:

  const foo = fn();
  bar += foo;
  

  In addition to fixing this correctness bug, this release also improves esbuild's output in the case where all values being skipped over are primitives:

  function toneMapLuminance(r, g, b) {
    let hdr = luminance(r, g, b)
    let decay = 1 / (1 + hdr)
    return 1 - decay
  }
  

  Previous releases of esbuild didn't substitute these single-use variables here, but esbuild will now minify this to the following code starting with this release:

  function toneMapLuminance(e,n,a){return 1-1/(1+luminance(e,n,a))}
  

v0.15.11

• Fix various edge cases regarding template tags and this (#2610)

  This release fixes some bugs where the value of this wasn't correctly preserved when evaluating template tags in a few edge cases. These edge cases are listed below:

  async function test() {
  

... (truncated)

Sourced from esbuild's changelog.

0.15.12

• Fix minifier correctness bug with single-use substitutions (#2619)

  When minification is enabled, esbuild will attempt to eliminate variables that are only used once in certain cases. For example, esbuild minifies this code:

  function getEmailForUser(name) {
    let users = db.table('users');
    let user = users.find({ name });
    let email = user?.get('email');
    return email;
  }
  

  into this code:

  function getEmailForUser(e){return db.table("users").find({name:e})?.get("email")}
  

  However, this transformation had a bug where esbuild did not correctly consider the "read" part of binary read-modify-write assignment operators. For example, it's incorrect to minify the following code into bar += fn() because the call to fn() might modify bar:

  const foo = fn();
  bar += foo;
  

  In addition to fixing this correctness bug, this release also improves esbuild's output in the case where all values being skipped over are primitives:

  function toneMapLuminance(r, g, b) {
    let hdr = luminance(r, g, b)
    let decay = 1 / (1 + hdr)
    return 1 - decay
  }
  

  Previous releases of esbuild didn't substitute these single-use variables here, but esbuild will now minify this to the following code starting with this release:

  function toneMapLuminance(e,n,a){return 1-1/(1+luminance(e,n,a))}
  

0.15.11

• Fix various edge cases regarding template tags and this (#2610)

  This release fixes some bugs where the value of this wasn't correctly preserved when evaluating template tags in a few edge cases. These edge cases are listed below:

... (truncated)

• 223e6ea publish 0.15.12 to npm
• ccc8e8b fix #2619: bug with single-use substitutions
• 4608721 ci: update github actions (#2612)
• 0bb62e8 publish 0.15.11 to npm
• 9c89f14 update go 1.19.1 => 1.19.2
• 0d8ec0a fix #2610: template tag edge cases with this
• a4a45f3 fix indentation in tests
• 81fa2ca more info in yarn pnp error messages (#2585)
• fdbea94 fixes for NewStringInJSLog
• aaae34e publish 0.15.10 to npm
• Additional commits viewable in compare view

You can trigger Dependabot actions by commenting on this PR:

• @dependabot rebase will rebase this PR
• @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
• @dependabot merge will merge this PR after your CI passes on it
• @dependabot squash and merge will squash and merge this PR after your CI passes on it
• @dependabot cancel merge will cancel a previously requested merge and block automerging
• @dependabot reopen will reopen this PR if it is closed
• @dependabot close will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually
• @dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)

Sourced from esbuild's releases.

v0.15.11

• Fix various edge cases regarding template tags and this (#2610)

  This release fixes some bugs where the value of this wasn't correctly preserved when evaluating template tags in a few edge cases. These edge cases are listed below:

  async function test() {
    class Foo { foo() { return this } }
    class Bar extends Foo {
      a = async () => super.foo``
      b = async () => super['foo']``
      c = async (foo) => super[foo]``
    }
    function foo() { return this }
    const obj = { foo }
    const bar = new Bar
    console.log(
      (await bar.a()) === bar,
      (await bar.b()) === bar,
      (await bar.c('foo')) === bar,
      { foo }.foo``.foo === foo,
      (true && obj.foo)`` !== obj,
      (false || obj.foo)`` !== obj,
      (null ?? obj.foo)`` !== obj,
    )
  }
  test()
  

  Each edge case in the code above previously incorrectly printed false when run through esbuild with --minify --target=es6 but now correctly prints true. These edge cases are unlikely to have affected real-world code.

v0.15.10

• Add support for node's "pattern trailers" syntax (#2569)

  After esbuild implemented node's exports feature in package.json, node changed the feature to also allow text after * wildcards in patterns. Previously the * was required to be at the end of the pattern. It lets you do something like this:

  {
    "exports": {
      "./features/*": "./features/*.js",
      "./features/*.js": "./features/*.js"
    }
  }
  

  With this release, esbuild now supports these types of patterns too.

• Fix subpath imports with Yarn PnP (#2545)

  Node has a little-used feature called subpath imports which are package-internal imports that start with # and that go through the imports map in package.json. Previously esbuild had a bug that caused esbuild to not handle these correctly in packages installed via Yarn's "Plug'n'Play" installation strategy. The problem was that subpath imports were being checked after Yarn PnP instead of before. This release reorders these checks, which should allow subpath imports to work in this case.

... (truncated)

Sourced from esbuild's changelog.

0.15.11

• Fix various edge cases regarding template tags and this (#2610)

  This release fixes some bugs where the value of this wasn't correctly preserved when evaluating template tags in a few edge cases. These edge cases are listed below:

  async function test() {
    class Foo { foo() { return this } }
    class Bar extends Foo {
      a = async () => super.foo``
      b = async () => super['foo']``
      c = async (foo) => super[foo]``
    }
    function foo() { return this }
    const obj = { foo }
    const bar = new Bar
    console.log(
      (await bar.a()) === bar,
      (await bar.b()) === bar,
      (await bar.c('foo')) === bar,
      { foo }.foo``.foo === foo,
      (true && obj.foo)`` !== obj,
      (false || obj.foo)`` !== obj,
      (null ?? obj.foo)`` !== obj,
    )
  }
  test()
  

  Each edge case in the code above previously incorrectly printed false when run through esbuild with --minify --target=es6 but now correctly prints true. These edge cases are unlikely to have affected real-world code.

0.15.10

• Add support for node's "pattern trailers" syntax (#2569)

  After esbuild implemented node's exports feature in package.json, node changed the feature to also allow text after * wildcards in patterns. Previously the * was required to be at the end of the pattern. It lets you do something like this:

  {
    "exports": {
      "./features/*": "./features/*.js",
      "./features/*.js": "./features/*.js"
    }
  }
  

  With this release, esbuild now supports these types of patterns too.

• Fix subpath imports with Yarn PnP (#2545)

... (truncated)

• 0bb62e8 publish 0.15.11 to npm
• 9c89f14 update go 1.19.1 => 1.19.2
• 0d8ec0a fix #2610: template tag edge cases with this
• a4a45f3 fix indentation in tests
• 81fa2ca more info in yarn pnp error messages (#2585)
• fdbea94 fixes for NewStringInJSLog
• aaae34e publish 0.15.10 to npm
• 4bd03f3 fix #1861, fix #2565: add cssBundle to metafile
• c55000d Fix subpath imports with Yarn PnP (#2547)
• 1bce251 fix transform tsconfigRaw type (#2568)
• Additional commits viewable in compare view

You can trigger Dependabot actions by commenting on this PR:

• @dependabot rebase will rebase this PR
• @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
• @dependabot merge will merge this PR after your CI passes on it
• @dependabot squash and merge will squash and merge this PR after your CI passes on it
• @dependabot cancel merge will cancel a previously requested merge and block automerging
• @dependabot reopen will reopen this PR if it is closed
• @dependabot close will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually
• @dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)

Sourced from esbuild's releases.

v0.15.10

• Add support for node's "pattern trailers" syntax (#2569)

  After esbuild implemented node's exports feature in package.json, node changed the feature to also allow text after * wildcards in patterns. Previously the * was required to be at the end of the pattern. It lets you do something like this:

  {
    "exports": {
      "./features/*": "./features/*.js",
      "./features/*.js": "./features/*.js"
    }
  }
  

  With this release, esbuild now supports these types of patterns too.

• Fix subpath imports with Yarn PnP (#2545)

  Node has a little-used feature called subpath imports which are package-internal imports that start with # and that go through the imports map in package.json. Previously esbuild had a bug that caused esbuild to not handle these correctly in packages installed via Yarn's "Plug'n'Play" installation strategy. The problem was that subpath imports were being checked after Yarn PnP instead of before. This release reorders these checks, which should allow subpath imports to work in this case.

• Link from JS to CSS in the metafile (#1861, #2565)

  When you import CSS into a bundled JS file, esbuild creates a parallel CSS bundle next to your JS bundle. So if app.ts imports some CSS files and you bundle it, esbuild will give you app.js and app.css. You would then add both <script src="app.js"></script> and <link href="app.css" rel="stylesheet"> to your HTML to include everything in the page. This approach is more efficient than having esbuild insert additional JavaScript into app.js that downloads and includes app.css because it means the browser can download and parse both the CSS and the JS in parallel (and potentially apply the CSS before the JS has even finished downloading).

  However, sometimes it's difficult to generate the <link> tag. One case is when you've added [hash] to the entry names setting to include a content hash in the file name. Then the file name will look something like app-GX7G2SBE.css and may change across subsequent builds. You can tell esbuild to generate build metadata using the metafile API option but the metadata only tells you which generated JS bundle corresponds to a JS entry point (via the entryPoint property), not which file corresponds to the associated CSS bundle. Working around this was hacky and involved string manipulation.

  This release adds the cssBundle property to the metafile to make this easier. It's present on the metadata for the generated JS bundle and points to the associated CSS bundle. So to generate the HTML tags for a given JS entry point, you first find the output file with the entryPoint you are looking for (and put that in a <script> tag), then check for the cssBundle property to find the associated CSS bundle (and put that in a <link> tag).

  One thing to note is that there is deliberately no jsBundle property mapping the other way because it's not a 1:1 relationship. Two JS bundles can share the same CSS bundle in the case where the associated CSS bundles have the same name and content. In that case there would be no one value for a hypothetical jsBundle property to have.

v0.15.9

• Fix an obscure npm package installation issue with --omit=optional (#2558)

  The previous release introduced a regression with npm install esbuild --omit=optional where the file node_modules/.bin/esbuild would no longer be present after installation. That could cause any package scripts which used the esbuild command to no longer work. This release fixes the regression so node_modules/.bin/esbuild should now be present again after installation. This regression only affected people installing esbuild using npm with either the --omit=optional or --no-optional flag, which is a somewhat unusual situation.

  More details:

  The reason for this regression is due to some obscure npm implementation details. Since the Go compiler doesn't support trivial cross-compiling on certain Android platforms, esbuild's installer installs a WebAssembly shim on those platforms instead. In the previous release I attempted to simplify esbuild's WebAssembly shims to depend on the esbuild-wasm package instead of including another whole copy of the WebAssembly binary (to make publishing faster and to save on file system space after installation). However, both the esbuild package and the esbuild-wasm package provide a binary called esbuild and it turns out that adding esbuild-wasm as a nested dependency of the esbuild package (specifically esbuild optionally depends on @esbuild/android-arm which depends on esbuild-wasm) caused npm to be confused about what node_modules/.bin/esbuild is supposed to be.

  It's pretty strange and unexpected that disabling the installation of optional dependencies altogether would suddenly cause an optional dependency's dependency to conflict with the top-level package. What happens under the hood is that if --omit=optional is present, npm attempts to uninstall the esbuild-wasm nested dependency at the end of npm install (even though the esbuild-wasm package was never installed due to --omit=optional). This uninstallation causes node_modules/.bin/esbuild to be deleted.

  After doing a full investigation, I discovered that npm's handling of the .bin directory is deliberately very brittle. When multiple packages in the dependency tree put something in .bin with the same name, the end result is non-deterministic/random. What you get in .bin might be from one package, from the other package, or might be missing entirely. The workaround suggested by npm is to just avoid having two packages that put something in .bin with the same name. So this was fixed by making the @esbuild/android-arm and esbuild-android-64 packages each include another whole copy of the WebAssembly binary, which works because these packages don't put anything in .bin.

v0.15.8

• Fix JSX name collision edge case (#2534)

  Code generated by esbuild could have a name collision in the following edge case:

  • The JSX transformation mode is set to automatic, which causes import statements to be inserted
  • An element uses a {...spread} followed by a key={...}, which uses the legacy createElement fallback imported from react

... (truncated)

Sourced from esbuild's changelog.

0.15.10

• Add support for node's "pattern trailers" syntax (#2569)

  After esbuild implemented node's exports feature in package.json, node changed the feature to also allow text after * wildcards in patterns. Previously the * was required to be at the end of the pattern. It lets you do something like this:

  {
    "exports": {
      "./features/*": "./features/*.js",
      "./features/*.js": "./features/*.js"
    }
  }
  

  With this release, esbuild now supports these types of patterns too.

• Fix subpath imports with Yarn PnP (#2545)

  Node has a little-used feature called subpath imports which are package-internal imports that start with # and that go through the imports map in package.json. Previously esbuild had a bug that caused esbuild to not handle these correctly in packages installed via Yarn's "Plug'n'Play" installation strategy. The problem was that subpath imports were being checked after Yarn PnP instead of before. This release reorders these checks, which should allow subpath imports to work in this case.

• Link from JS to CSS in the metafile (#1861, #2565)

  When you import CSS into a bundled JS file, esbuild creates a parallel CSS bundle next to your JS bundle. So if app.ts imports some CSS files and you bundle it, esbuild will give you app.js and app.css. You would then add both <script src="app.js"></script> and <link href="app.css" rel="stylesheet"> to your HTML to include everything in the page. This approach is more efficient than having esbuild insert additional JavaScript into app.js that downloads and includes app.css because it means the browser can download and parse both the CSS and the JS in parallel (and potentially apply the CSS before the JS has even finished downloading).

  However, sometimes it's difficult to generate the <link> tag. One case is when you've added [hash] to the entry names setting to include a content hash in the file name. Then the file name will look something like app-GX7G2SBE.css and may change across subsequent builds. You can tell esbuild to generate build metadata using the metafile API option but the metadata only tells you which generated JS bundle corresponds to a JS entry point (via the entryPoint property), not which file corresponds to the associated CSS bundle. Working around this was hacky and involved string manipulation.

  This release adds the cssBundle property to the metafile to make this easier. It's present on the metadata for the generated JS bundle and points to the associated CSS bundle. So to generate the HTML tags for a given JS entry point, you first find the output file with the entryPoint you are looking for (and put that in a <script> tag), then check for the cssBundle property to find the associated CSS bundle (and put that in a <link> tag).

  One thing to note is that there is deliberately no jsBundle property mapping the other way because it's not a 1:1 relationship. Two JS bundles can share the same CSS bundle in the case where the associated CSS bundles have the same name and content. In that case there would be no one value for a hypothetical jsBundle property to have.

0.15.9

• Fix an obscure npm package installation issue with --omit=optional (#2558)

  The previous release introduced a regression with npm install esbuild --omit=optional where the file node_modules/.bin/esbuild would no longer be present after installation. That could cause any package scripts which used the esbuild command to no longer work. This release fixes the regression so node_modules/.bin/esbuild should now be present again after installation. This regression only affected people installing esbuild using npm with either the --omit=optional or --no-optional flag, which is a somewhat unusual situation.

  More details:

  The reason for this regression is due to some obscure npm implementation details. Since the Go compiler doesn't support trivial cross-compiling on certain Android platforms, esbuild's installer installs a WebAssembly shim on those platforms instead. In the previous release I attempted to simplify esbuild's WebAssembly shims to depend on the esbuild-wasm package instead of including another whole copy of the WebAssembly binary (to make publishing faster and to save on file system space after installation). However, both the esbuild package and the esbuild-wasm package provide a binary called esbuild and it turns out that adding esbuild-wasm as a nested dependency of the esbuild package (specifically esbuild optionally depends on @esbuild/android-arm which depends on esbuild-wasm) caused npm to be confused about what node_modules/.bin/esbuild is supposed to be.

  It's pretty strange and unexpected that disabling the installation of optional dependencies altogether would suddenly cause an optional dependency's dependency to conflict with the top-level package. What happens under the hood is that if --omit=optional is present, npm attempts to uninstall the esbuild-wasm nested dependency at the end of npm install (even though the esbuild-wasm package was never installed due to --omit=optional). This uninstallation causes node_modules/.bin/esbuild to be deleted.

  After doing a full investigation, I discovered that npm's handling of the .bin directory is deliberately very brittle. When multiple packages in the dependency tree put something in .bin with the same name, the end result is non-deterministic/random. What you get in .bin might be from one package, from the other package, or might be missing entirely. The workaround suggested by npm is to just avoid having two packages that put something in .bin with the same name. So this was fixed by making the @esbuild/android-arm and esbuild-android-64 packages each include another whole copy of the WebAssembly binary, which works because these packages don't put anything in .bin.

0.15.8

• Fix JSX name collision edge case (#2534)

  Code generated by esbuild could have a name collision in the following edge case:

... (truncated)

• aaae34e publish 0.15.10 to npm
• 4bd03f3 fix #1861, fix #2565: add cssBundle to metafile
• c55000d Fix subpath imports with Yarn PnP (#2547)
• 1bce251 fix transform tsconfigRaw type (#2568)
• efd0af6 fix #2569: support node's "pattern trailer" syntax
• 23709e2 makefile: fix build validation bug
• 085265a publish 0.15.9 to npm
• f84de90 use a custom message for macOS architecture issues
• ba91ed1 makefile: publish four at a time again
• e55f980 add validate to clean
• Additional commits viewable in compare view

You can trigger Dependabot actions by commenting on this PR:

• @dependabot rebase will rebase this PR
• @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
• @dependabot merge will merge this PR after your CI passes on it
• @dependabot squash and merge will squash and merge this PR after your CI passes on it
• @dependabot cancel merge will cancel a previously requested merge and block automerging
• @dependabot reopen will reopen this PR if it is closed
• @dependabot close will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually
• @dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)

Sourced from esbuild's releases.

v0.15.9

• Fix an obscure npm package installation issue with --omit=optional (#2558)

  The previous release introduced a regression with npm install esbuild --omit=optional where the file node_modules/.bin/esbuild would no longer be present after installation. That could cause any package scripts which used the esbuild command to no longer work. This release fixes the regression so node_modules/.bin/esbuild should now be present again after installation. This regression only affected people installing esbuild using npm with either the --omit=optional or --no-optional flag, which is a somewhat unusual situation.

  More details:

  The reason for this regression is due to some obscure npm implementation details. Since the Go compiler doesn't support trivial cross-compiling on certain Android platforms, esbuild's installer installs a WebAssembly shim on those platforms instead. In the previous release I attempted to simplify esbuild's WebAssembly shims to depend on the esbuild-wasm package instead of including another whole copy of the WebAssembly binary (to make publishing faster and to save on file system space after installation). However, both the esbuild package and the esbuild-wasm package provide a binary called esbuild and it turns out that adding esbuild-wasm as a nested dependency of the esbuild package (specifically esbuild optionally depends on @esbuild/android-arm which depends on esbuild-wasm) caused npm to be confused about what node_modules/.bin/esbuild is supposed to be.

  It's pretty strange and unexpected that disabling the installation of optional dependencies altogether would suddenly cause an optional dependency's dependency to conflict with the top-level package. What happens under the hood is that if --omit=optional is present, npm attempts to uninstall the esbuild-wasm nested dependency at the end of npm install (even though the esbuild-wasm package was never installed due to --omit=optional). This uninstallation causes node_modules/.bin/esbuild to be deleted.

  After doing a full investigation, I discovered that npm's handling of the .bin directory is deliberately very brittle. When multiple packages in the dependency tree put something in .bin with the same name, the end result is non-deterministic/random. What you get in .bin might be from one package, from the other package, or might be missing entirely. The workaround suggested by npm is to just avoid having two packages that put something in .bin with the same name. So this was fixed by making the @esbuild/android-arm and esbuild-android-64 packages each include another whole copy of the WebAssembly binary, which works because these packages don't put anything in .bin.

v0.15.8

• Fix JSX name collision edge case (#2534)

  Code generated by esbuild could have a name collision in the following edge case:

  • The JSX transformation mode is set to automatic, which causes import statements to be inserted
  • An element uses a {...spread} followed by a key={...}, which uses the legacy createElement fallback imported from react
  • Another import uses a name that ends with react such as @remix-run/react
  • The output format has been set to CommonJS so that import statements are converted into require calls

  In this case, esbuild previously generated two variables with the same name import_react, like this:

  var import_react = require("react");
  var import_react2 = require("@remix-run/react");
  

  That bug is fixed in this release. The code generated by esbuild no longer contains a name collision.

• Fall back to WebAssembly on Android ARM (#1556, #1578, #2335, #2526)

  Go's compiler supports trivial cross-compiling to almost all platforms without installing any additional software other than the Go compiler itself. This has made it very easy for esbuild to publish native binary executables for many platforms. However, it strangely doesn't support cross-compiling to Android ARM without installing the Android build tools.

  So instead of publishing a native esbuild binary executable to npm, this release publishes a WebAssembly fallback build. This is essentially the same as the esbuild-wasm package but it's installed automatically when you install the esbuild package on Android ARM. So packages that depend on the esbuild package should now work on Android ARM. This change has not yet been tested end-to-end because I don't have a 32-bit Android ARM device myself, but in theory it should work.

  This inherits the drawbacks of WebAssembly including significantly slower performance than native as well as potentially also more severe memory usage limitations and lack of certain features (e.g. --serve). If you want to use a native binary executable of esbuild on Android ARM, you may be able to build it yourself from source after installing the Android build tools.

• Attempt to better support Yarn's ignorePatternData feature (#2495)

  Part of resolving paths in a project using Yarn's Plug'n'Play feature involves evaluating a regular expression in the ignorePatternData property of .pnp.data.json. However, it turns out that the particular regular expressions generated by Yarn use some syntax that works with JavaScript regular expressions but that does not work with Go regular expressions.

  In this release, esbuild will now strip some of the the problematic syntax from the regular expression before compiling it, which should hopefully allow it to be compiled by Go's regular expression engine. The specific character sequences that esbuild currently strips are as follows:

  • (?!\.)
  • (?!(?:^|\/)\.)
  • (?!\.{1,2}(?:\/|$))
  • (?!(?:^|\/)\.{1,2}(?:\/|$))

... (truncated)

Sourced from esbuild's changelog.

0.15.9

• Fix an obscure npm package installation issue with --omit=optional (#2558)

  The previous release introduced a regression with npm install esbuild --omit=optional where the file node_modules/.bin/esbuild would no longer be present after installation. That could cause any package scripts which used the esbuild command to no longer work. This release fixes the regression so node_modules/.bin/esbuild should now be present again after installation. This regression only affected people installing esbuild using npm with either the --omit=optional or --no-optional flag, which is a somewhat unusual situation.

  More details:

  The reason for this regression is due to some obscure npm implementation details. Since the Go compiler doesn't support trivial cross-compiling on certain Android platforms, esbuild's installer installs a WebAssembly shim on those platforms instead. In the previous release I attempted to simplify esbuild's WebAssembly shims to depend on the esbuild-wasm package instead of including another whole copy of the WebAssembly binary (to make publishing faster and to save on file system space after installation). However, both the esbuild package and the esbuild-wasm package provide a binary called esbuild and it turns out that adding esbuild-wasm as a nested dependency of the esbuild package (specifically esbuild optionally depends on @esbuild/android-arm which depends on esbuild-wasm) caused npm to be confused about what node_modules/.bin/esbuild is supposed to be.

  It's pretty strange and unexpected that disabling the installation of optional dependencies altogether would suddenly cause an optional dependency's dependency to conflict with the top-level package. What happens under the hood is that if --omit=optional is present, npm attempts to uninstall the esbuild-wasm nested dependency at the end of npm install (even though the esbuild-wasm package was never installed due to --omit=optional). This uninstallation causes node_modules/.bin/esbuild to be deleted.

  After doing a full investigation, I discovered that npm's handling of the .bin directory is deliberately very brittle. When multiple packages in the dependency tree put something in .bin with the same name, the end result is non-deterministic/random. What you get in .bin might be from one package, from the other package, or might be missing entirely. The workaround suggested by npm is to just avoid having two packages that put something in .bin with the same name. So this was fixed by making the @esbuild/android-arm and esbuild-android-64 packages each include another whole copy of the WebAssembly binary, which works because these packages don't put anything in .bin.

0.15.8

• Fix JSX name collision edge case (#2534)

  Code generated by esbuild could have a name collision in the following edge case:

  • The JSX transformation mode is set to automatic, which causes import statements to be inserted
  • An element uses a {...spread} followed by a key={...}, which uses the legacy createElement fallback imported from react
  • Another import uses a name that ends with react such as @remix-run/react
  • The output format has been set to CommonJS so that import statements are converted into require calls

  In this case, esbuild previously generated two variables with the same name import_react, like this:

  var import_react = require("react");
  var import_react2 = require("@remix-run/react");
  

  That bug is fixed in this release. The code generated by esbuild no longer contains a name collision.

• Fall back to WebAssembly on Android ARM (#1556, #1578, #2335, #2526)

  Go's compiler supports trivial cross-compiling to almost all platforms without installing any additional software other than the Go compiler itself. This has made it very easy for esbuild to publish native binary executables for many platforms. However, it strangely doesn't support cross-compiling to Android ARM without installing the Android build tools.

  So instead of publishing a native esbuild binary executable to npm, this release publishes a WebAssembly fallback build. This is essentially the same as the esbuild-wasm package but it's installed automatically when you install the esbuild package on Android ARM. So packages that depend on the esbuild package should now work on Android ARM. This change has not yet been tested end-to-end because I don't have a 32-bit Android ARM device myself, but in theory it should work.

  This inherits the drawbacks of WebAssembly including significantly slower performance than native as well as potentially also more severe memory usage limitations and lack of certain features (e.g. --serve). If you want to use a native binary executable of esbuild on Android ARM, you may be able to build it yourself from source after installing the Android build tools.

• Attempt to better support Yarn's ignorePatternData feature (#2495)

  Part of resolving paths in a project using Yarn's Plug'n'Play feature involves evaluating a regular expression in the ignorePatternData property of .pnp.data.json. However, it turns out that the particular regular expressions generated by Yarn use some syntax that works with JavaScript regular expressions but that does not work with Go regular expressions.

  In this release, esbuild will now strip some of the the problematic syntax from the regular expression before compiling it, which should hopefully allow it to be compiled by Go's regular expression engine. The specific character sequences that esbuild currently strips are as follows:

  • (?!\.)
  • (?!(?:^|\/)\.)

... (truncated)

• 085265a publish 0.15.9 to npm
• f84de90 use a custom message for macOS architecture issues
• ba91ed1 makefile: publish four at a time again
• e55f980 add validate to clean
• 02d3ded build all platforms in ci
• 44c5417 fix android arm package in make clean
• eb9de88 additional platform target updates
• 758d4e1 fix #2558: remove esbuild-wasm package nesting
• a333130 update platform targets
• 8b3bb3b update wasm-napi-exit0 targets
• Additional commits viewable in compare view

You can trigger Dependabot actions by commenting on this PR:

• @dependabot rebase will rebase this PR
• @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
• @dependabot merge will merge this PR after your CI passes on it
• @dependabot squash and merge will squash and merge this PR after your CI passes on it
• @dependabot cancel merge will cancel a previously requested merge and block automerging
• @dependabot reopen will reopen this PR if it is closed
• @dependabot close will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually
• @dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)

Sourced from esbuild's releases.

v0.15.8

• Fix JSX name collision edge case (#2534)

  Code generated by esbuild could have a name collision in the following edge case:

  • The JSX transformation mode is set to automatic, which causes import statements to be inserted
  • An element uses a {...spread} followed by a key={...}, which uses the legacy createElement fallback imported from react
  • Another import uses a name that ends with react such as @remix-run/react
  • The output format has been set to CommonJS so that import statements are converted into require calls

  In this case, esbuild previously generated two variables with the same name import_react, like this:

  var import_react = require("react");
  var import_react2 = require("@remix-run/react");
  

  That bug is fixed in this release. The code generated by esbuild no longer contains a name collision.

• Fall back to WebAssembly on Android ARM (#1556, #1578, #2335, #2526)

  Go's compiler supports trivial cross-compiling to almost all platforms without installing any additional software other than the Go compiler itself. This has made it very easy for esbuild to publish native binary executables for many platforms. However, it strangely doesn't support cross-compiling to Android ARM without installing the Android build tools.

  So instead of publishing a native esbuild binary executable to npm, this release publishes a WebAssembly fallback build. This is essentially the same as the esbuild-wasm package but it's installed automatically when you install the esbuild package on Android ARM. So packages that depend on the esbuild package should now work on Android ARM. This change has not yet been tested end-to-end because I don't have a 32-bit Android ARM device myself, but in theory it should work.

  This inherits the drawbacks of WebAssembly including significantly slower performance than native as well as potentially also more severe memory usage limitations and lack of certain features (e.g. --serve). If you want to use a native binary executable of esbuild on Android ARM, you may be able to build it yourself from source after installing the Android build tools.

• Attempt to better support Yarn's ignorePatternData feature (#2495)

  Part of resolving paths in a project using Yarn's Plug'n'Play feature involves evaluating a regular expression in the ignorePatternData property of .pnp.data.json. However, it turns out that the particular regular expressions generated by Yarn use some syntax that works with JavaScript regular expressions but that does not work with Go regular expressions.

  In this release, esbuild will now strip some of the the problematic syntax from the regular expression before compiling it, which should hopefully allow it to be compiled by Go's regular expression engine. The specific character sequences that esbuild currently strips are as follows:

  • (?!\.)
  • (?!(?:^|\/)\.)
  • (?!\.{1,2}(?:\/|$))
  • (?!(?:^|\/)\.{1,2}(?:\/|$))

  These seem to be used by Yarn to avoid the . and .. path segments in the middle of relative paths. The removal of these character sequences seems relatively harmless in this case since esbuild shouldn't ever generate such path segments. This change should add support to esbuild for Yarn's pnpIgnorePatterns feature.

• Fix non-determinism issue with legacy block-level function declarations and strict mode (#2537)

  When function declaration statements are nested inside a block in strict mode, they are supposed to only be available within that block's scope. But in "sloppy mode" (which is what non-strict mode is commonly called), they are supposed to be available within the whole function's scope:

  // This returns 1 due to strict mode
  function test1() {
    'use strict'
    function fn() { return 1 }
    if (true) { function fn() { return 2 } }
  

... (truncated)

Sourced from esbuild's changelog.

0.15.8

• Fix JSX name collision edge case (#2534)

  Code generated by esbuild could have a name collision in the following edge case:

  • The JSX transformation mode is set to automatic, which causes import statements to be inserted
  • An element uses a {...spread} followed by a key={...}, which uses the legacy createElement fallback imported from react
  • Another import uses a name that ends with react such as @remix-run/react
  • The output format has been set to CommonJS so that import statements are converted into require calls

  In this case, esbuild previously generated two variables with the same name import_react, like this:

  var import_react = require("react");
  var import_react2 = require("@remix-run/react");
  

  That bug is fixed in this release. The code generated by esbuild no longer contains a name collision.

• Fall back to WebAssembly on Android ARM (#1556, #1578, #2335, #2526)

  Go's compiler supports trivial cross-compiling to almost all platforms without installing any additional software other than the Go compiler itself. This has made it very easy for esbuild to publish native binary executables for many platforms. However, it strangely doesn't support cross-compiling to Android ARM without installing the Android build tools.

  So instead of publishing a native esbuild binary executable to npm, this release publishes a WebAssembly fallback build. This is essentially the same as the esbuild-wasm package but it's installed automatically when you install the esbuild package on Android ARM. So packages that depend on the esbuild package should now work on Android ARM. This change has not yet been tested end-to-end because I don't have a 32-bit Android ARM device myself, but in theory it should work.

  This inherits the drawbacks of WebAssembly including significantly slower performance than native as well as potentially also more severe memory usage limitations and lack of certain features (e.g. --serve). If you want to use a native binary executable of esbuild on Android ARM, you may be able to build it yourself from source after installing the Android build tools.

• Attempt to better support Yarn's ignorePatternData feature (#2495)

  Part of resolving paths in a project using Yarn's Plug'n'Play feature involves evaluating a regular expression in the ignorePatternData property of .pnp.data.json. However, it turns out that the particular regular expressions generated by Yarn use some syntax that works with JavaScript regular expressions but that does not work with Go regular expressions.

  In this release, esbuild will now strip some of the the problematic syntax from the regular expression before compiling it, which should hopefully allow it to be compiled by Go's regular expression engine. The specific character sequences that esbuild currently strips are as follows:

  • (?!\.)
  • (?!(?:^|\/)\.)
  • (?!\.{1,2}(?:\/|$))
  • (?!(?:^|\/)\.{1,2}(?:\/|$))

  These seem to be used by Yarn to avoid the . and .. path segments in the middle of relative paths. The removal of these character sequences seems relatively harmless in this case since esbuild shouldn't ever generate such path segments. This change should add support to esbuild for Yarn's pnpIgnorePatterns feature.

• Fix non-determinism issue with legacy block-level function declarations and strict mode (#2537)

  When function declaration statements are nested inside a block in strict mode, they are supposed to only be available within that block's scope. But in "sloppy mode" (which is what non-strict mode is commonly called), they are supposed to be available within the whole function's scope:

  // This returns 1 due to strict mode
  function test1() {
    'use strict'
    function fn() { return 1 }
  

... (truncated)

• 7553dbe publish 0.15.8 to npm
• d65315a Add JSX side effects option (#2546)
• a6acbaa minify static object spread in jsx props
• c9b24d8 fix #2555: parse @keyframes with string namems
• 93e068d fix #2557: remove warning about top-level this
• be4e272 fix #2541: split changelog by year
• 3e2374c fix #2537: sort map keys to fix non-determinism
• 112a033 turn 64bit android package into a simple shim
• a849b7a add missing file to make clean
• a18c9fa fix #2495: strip non-go ignorePatternData stuff
• Additional commits viewable in compare view

You can trigger Dependabot actions by commenting on this PR:

• @dependabot rebase will rebase this PR
• @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
• @dependabot merge will merge this PR after your CI passes on it
• @dependabot squash and merge will squash and merge this PR after your CI passes on it
• @dependabot cancel merge will cancel a previously requested merge and block automerging
• @dependabot reopen will reopen this PR if it is closed
• @dependabot close will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually
• @dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)

Sourced from esbuild's releases.

v0.15.7

• Add --watch=forever to allow esbuild to never terminate (#1511, #1885)

  Currently using esbuild's watch mode via --watch from the CLI will stop watching if stdin is closed. The rationale is that stdin is automatically closed by the OS when the parent process exits, so stopping watch mode when stdin is closed ensures that esbuild's watch mode doesn't keep running forever after the parent process has been closed. For example, it would be bad if you wrote a shell script that did esbuild --watch & to run esbuild's watch mode in the background, and every time you run the script it creates a new esbuild process that runs forever.

  However, there are cases when it makes sense for esbuild's watch mode to never exit. One such case is within a short-lived VM where the lifetime of all processes inside the VM is expected to be the lifetime of the VM. Previously you could easily do this by piping the output of a long-lived command into esbuild's stdin such as sleep 999999999 | esbuild --watch &. However, this possibility often doesn't occur to people, and it also doesn't work on Windows. People also sometimes attempt to keep esbuild open by piping an infinite stream of data to esbuild such as with esbuild --watch </dev/zero & which causes esbuild to spin at 100% CPU. So with this release, esbuild now has a --watch=forever flag that will not stop watch mode when stdin is closed.

• Work around PATH without node in install script (#2519)

  Some people install esbuild's npm package in an environment without the node command in their PATH. This fails on Windows because esbuild's install script runs the esbuild command before exiting as a sanity check, and on Windows the esbuild command has to be a JavaScript file because of some internal details about how npm handles the bin folder (specifically the esbuild command lacks the .exe extension, which is required on Windows). This release attempts to work around this problem by using process.execPath instead of "node" as the command for running node. In theory this means the installer can now still function on Windows if something is wrong with PATH.

v0.15.6

• Lower for await loops (#1930)

  This release lowers for await loops to the equivalent for loop containing await when esbuild is configured such that for await loops are unsupported. This transform still requires at least generator functions to be supported since esbuild's lowering of await currently relies on generators. This new transformation is mostly modeled after what the TypeScript compiler does. Here's an example:

  async function f() {
    for await (let x of y)
      x()
  }
  

  The code above will now become the following code with --target=es2017 (omitting the code for the __forAwait helper function):

  async function f() {
    try {
      for (var iter = __forAwait(y), more, temp, error; more = !(temp = await iter.next()).done; more = false) {
        let x = temp.value;
        x();
      }
    } catch (temp) {
      error = [temp];
    } finally {
      try {
        more && (temp = iter.return) && await temp.call(iter);
      } finally {
        if (error)
          throw error[0];
      }
    }
  }
  

• Automatically fix invalid supported configurations (#2497)

  The --target= setting lets you tell esbuild to target a specific version of one or more JavaScript runtimes such as chrome80,node14 and esbuild will restrict its output to only those features supported by all targeted JavaScript runtimes. More recently, esbuild introduced the --supported: setting that lets you override which features are supported on a per-feature basis. However, this now lets you configure nonsensical things such as --supported:async-await=false --supported:async-generator=true. Previously doing this could result in esbuild building successfully but producing invalid output.

  Starting with this release, esbuild will now attempt to automatically fix nonsensical feature override configurations by introducing more overrides until the configuration makes sense. So now the configuration from previous example will be changed such that async-await=false implies async-generator=false. The full list of implications that were introduced is below:

... (truncated)

Sourced from esbuild's changelog.

0.15.7

• Add --watch=forever to allow esbuild to never terminate (#1511, #1885)

  Currently using esbuild's watch mode via --watch from the CLI will stop watching if stdin is closed. The rationale is that stdin is automatically closed by the OS when the parent process exits, so stopping watch mode when stdin is closed ensures that esbuild's watch mode doesn't keep running forever after the parent process has been closed. For example, it would be bad if you wrote a shell script that did esbuild --watch & to run esbuild's watch mode in the background, and every time you run the script it creates a new esbuild process that runs forever.

  However, there are cases when it makes sense for esbuild's watch mode to never exit. One such case is within a short-lived VM where the lifetime of all processes inside the VM is expected to be the lifetime of the VM. Previously you could easily do this by piping the output of a long-lived command into esbuild's stdin such as sleep 999999999 | esbuild --watch &. However, this possibility often doesn't occur to people, and it also doesn't work on Windows. People also sometimes attempt to keep esbuild open by piping an infinite stream of data to esbuild such as with esbuild --watch </dev/zero & which causes esbuild to spin at 100% CPU. So with this release, esbuild now has a --watch=forever flag that will not stop watch mode when stdin is closed.

• Work around PATH without node in install script (#2519)

  Some people install esbuild's npm package in an environment without the node command in their PATH. This fails on Windows because esbuild's install script runs the esbuild command before exiting as a sanity check, and on Windows the esbuild command has to be a JavaScript file because of some internal details about how npm handles the bin folder (specifically the esbuild command lacks the .exe extension, which is required on Windows). This release attempts to work around this problem by using process.execPath instead of "node" as the command for running node. In theory this means the installer can now still function on Windows if something is wrong with PATH.

0.15.6

• Lower for await loops (#1930)

  This release lowers for await loops to the equivalent for loop containing await when esbuild is configured such that for await loops are unsupported. This transform still requires at least generator functions to be supported since esbuild's lowering of await currently relies on generators. This new transformation is mostly modeled after what the TypeScript compiler does. Here's an example:

  async function f() {
    for await (let x of y)
      x()
  }
  

  The code above will now become the following code with --target=es2017 (omitting the code for the __forAwait helper function):

  async function f() {
    try {
      for (var iter = __forAwait(y), more, temp, error; more = !(temp = await iter.next()).done; more = false) {
        let x = temp.value;
        x();
      }
    } catch (temp) {
      error = [temp];
    } finally {
      try {
        more && (temp = iter.return) && await temp.call(iter);
      } finally {
        if (error)
          throw error[0];
      }
    }
  }
  

• Automatically fix invalid supported configurations (#2497)

  The --target= setting lets you tell esbuild to target a specific version of one or more JavaScript runtimes such as chrome80,node14 and esbuild will restrict its output to only those features supported by all targeted JavaScript runtimes. More recently, esbuild introduced the --supported: setting that lets you override which features are supported on a per-feature basis. However, this now lets you configure nonsensical things such as --supported:async-await=false --supported:async-generator=true. Previously doing this could result in esbuild building successfully but producing invalid output.

... (truncated)

• c0b8a53 publish 0.15.7 to npm
• 976b57a validate await in shorthand destructuring
• 8ac7529 tests: ignore new top-level await test262 tests
• dbd21a8 tests: skip new features in test262
• 7331a34 ci: upgrade to yarn 3.2.3, enable more tests
• 31e1cee install script: tiny wasm tree-shaking improvement
• 0438f64 ci: run deno tests on windows
• 7549073 ci: pin deno version to avoid test flakes
• 6a26f59 tests: use unused test in node-unref-tests
• 037ffbb tests: remove source-map from js-api-tests
• Additional commits viewable in compare view

You can trigger Dependabot actions by commenting on this PR:

• @dependabot rebase will rebase this PR
• @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
• @dependabot merge will merge this PR after your CI passes on it
• @dependabot squash and merge will squash and merge this PR after your CI passes on it
• @dependabot cancel merge will cancel a previously requested merge and block automerging
• @dependabot reopen will reopen this PR if it is closed
• @dependabot close will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually
• @dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)

Sourced from esbuild's releases.

v0.16.10

• Change the default "legal comment" behavior again (#2745)

  The legal comments feature automatically gathers comments containing @license or @preserve and puts the comments somewhere (either in the generated code or in a separate file). This behavior used to be on by default but was disabled by default in version 0.16.0 because automatically inserting comments is potentially confusing and misleading. These comments can appear to be assigning the copyright of your code to another entity. And this behavior can be especially problematic if it happens automatically by default since you may not even be aware of it happening. For example, if you bundle the TypeScript compiler the preserving legal comments means your source code would contain this comment, which appears to be assigning the copyright of all of your code to Microsoft:

  /*! *****************************************************************************
  Copyright (c) Microsoft Corporation. All rights reserved.
  Licensed under the Apache License, Version 2.0 (the "License"); you may not use
  this file except in compliance with the License. You may obtain a copy of the
  License at http://www.apache.org/licenses/LICENSE-2.0
  THIS CODE IS PROVIDED ON AN AS IS BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
  KIND, EITHER EXPRESS OR IMPLIED, INCLUDING WITHOUT LIMITATION ANY IMPLIED
  WARRANTIES OR CONDITIONS OF TITLE, FITNESS FOR A PARTICULAR PURPOSE,
  MERCHANTABLITY OR NON-INFRINGEMENT.
  See the Apache Version 2.0 License for specific language governing permissions
  and limitations under the License.
  ***************************************************************************** */
  

  However, people have asked for this feature to be re-enabled by default. To resolve the confusion about what these comments are applying to, esbuild's default behavior will now be to attempt to describe which package the comments are coming from. So while this feature has been re-enabled by default, the output will now look something like this instead:

  /*! Bundled license information:
  typescript/lib/typescript.js:
  (*! *****************************************************************************
  Copyright (c) Microsoft Corporation. All rights reserved.
  Licensed under the Apache License, Version 2.0 (the "License"); you may not use
  this file except in compliance with the License. You may obtain a copy of the
  License at http://www.apache.org/licenses/LICENSE-2.0
  THIS CODE IS PROVIDED ON AN AS IS BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
  KIND, EITHER EXPRESS OR IMPLIED, INCLUDING WITHOUT LIMITATION ANY IMPLIED
  WARRANTIES OR CONDITIONS OF TITLE, FITNESS FOR A PARTICULAR PURPOSE,
  MERCHANTABLITY OR NON-INFRINGEMENT.
  See the Apache Version 2.0 License for specific language governing permissions
  and limitations under the License.
  ***************************************************************************** *)
  */
  

  Note that you can still customize this behavior with the --legal-comments= flag. For example, you can use --legal-comments=none to turn this off, or you can use --legal-comments=linked to put these comments in a separate .LEGAL.txt file instead.

• Enable external legal comments with the transform API (#2390)

  Previously esbuild's transform API only supported none, inline, or eof legal comments. With this release, external legal comments are now also supported with the transform API. This only applies to the JS and Go APIs, not to the CLI, and looks like this:

... (truncated)

Sourced from esbuild's changelog.

0.16.10

• Change the default "legal comment" behavior again (#2745)

  The legal comments feature automatically gathers comments containing @license or @preserve and puts the comments somewhere (either in the generated code or in a separate file). This behavior used to be on by default but was disabled by default in version 0.16.0 because automatically inserting comments is potentially confusing and misleading. These comments can appear to be assigning the copyright of your code to another entity. And this behavior can be especially problematic if it happens automatically by default since you may not even be aware of it happening. For example, if you bundle the TypeScript compiler the preserving legal comments means your source code would contain this comment, which appears to be assigning the copyright of all of your code to Microsoft:

  /*! *****************************************************************************
  Copyright (c) Microsoft Corporation. All rights reserved.
  Licensed under the Apache License, Version 2.0 (the "License"); you may not use
  this file except in compliance with the License. You may obtain a copy of the
  License at http://www.apache.org/licenses/LICENSE-2.0
  THIS CODE IS PROVIDED ON AN AS IS BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
  KIND, EITHER EXPRESS OR IMPLIED, INCLUDING WITHOUT LIMITATION ANY IMPLIED
  WARRANTIES OR CONDITIONS OF TITLE, FITNESS FOR A PARTICULAR PURPOSE,
  MERCHANTABLITY OR NON-INFRINGEMENT.
  See the Apache Version 2.0 License for specific language governing permissions
  and limitations under the License.
  ***************************************************************************** */
  

  However, people have asked for this feature to be re-enabled by default. To resolve the confusion about what these comments are applying to, esbuild's default behavior will now be to attempt to describe which package the comments are coming from. So while this feature has been re-enabled by default, the output will now look something like this instead:

  /*! Bundled license information:
  typescript/lib/typescript.js:
  (*! *****************************************************************************
  Copyright (c) Microsoft Corporation. All rights reserved.
  Licensed under the Apache License, Version 2.0 (the "License"); you may not use
  this file except in compliance with the License. You may obtain a copy of the
  License at http://www.apache.org/licenses/LICENSE-2.0
  THIS CODE IS PROVIDED ON AN AS IS BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
  KIND, EITHER EXPRESS OR IMPLIED, INCLUDING WITHOUT LIMITATION ANY IMPLIED
  WARRANTIES OR CONDITIONS OF TITLE, FITNESS FOR A PARTICULAR PURPOSE,
  MERCHANTABLITY OR NON-INFRINGEMENT.
  See the Apache Version 2.0 License for specific language governing permissions
  and limitations under the License.
  ***************************************************************************** *)
  */
  

  Note that you can still customize this behavior with the --legal-comments= flag. For example, you can use --legal-comments=none to turn this off, or you can use --legal-comments=linked to put these comments in a separate .LEGAL.txt file instead.

• Enable external legal comments with the transform API (#2390)

... (truncated)

• 0fea6ae publish 0.16.10 to npm
• 270a210 fix #2715: allow package subpaths with alias
• 1ec8085 fix #2390: transform w/ external legal comments
• 6a73c5e fix #2757: duplicate function definition edge case
• 4cc9999 option to not escape \</script> and \</style>
• 47dd4de fix #2745: another change to legal comments
• da0c253 fix default wasm name for deno to esbuild.wasm
• 29ae56a publish 0.16.9 to npm
• d2aa4eb fix lexically-declared names in strict mode
• 0c15c1e implement test262 json module loading
• Additional commits viewable in compare view

You can trigger Dependabot actions by commenting on this PR:

• @dependabot rebase will rebase this PR
• @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
• @dependabot merge will merge this PR after your CI passes on it
• @dependabot squash and merge will squash and merge this PR after your CI passes on it
• @dependabot cancel merge will cancel a previously requested merge and block automerging
• @dependabot reopen will reopen this PR if it is closed
• @dependabot close will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually
• @dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)