Sourced from esbuild's releases.

v0.16.12

• Loader defaults to js for extensionless files (#2776)

  Certain packages contain files without an extension. For example, the yargs package contains the file yargs/yargs which has no extension. Node, Webpack, and Parcel can all understand code that imports yargs/yargs because they assume that the file is JavaScript. However, esbuild was previously unable to understand this code because it relies on the file extension to tell it how to interpret the file. With this release, esbuild will now assume files without an extension are JavaScript files. This can be customized by setting the loader for "" (the empty string, representing files without an extension) to another loader. For example, if you want files without an extension to be treated as CSS instead, you can do that like this:

  • CLI:

    esbuild --bundle --loader:=css
    

  • JS:

    esbuild.build({
      bundle: true,
      loader: { '': 'css' },
    })
    

  • Go:

    api.Build(api.BuildOptions{
      Bundle: true,
      Loader: map[string]api.Loader{"": api.LoaderCSS},
    })
    

  In addition, the "type" field in package.json files now only applies to files with an explicit .js, .jsx, .ts, or .tsx extension. Previously it was incorrectly applied by esbuild to all files that had an extension other than .mjs, .mts, .cjs, or .cts including extensionless files. So for example an extensionless file in a "type": "module" package is now treated as CommonJS instead of ESM.

v0.16.11

• Avoid a syntax error in the presence of direct eval (#2761)

  The behavior of nested function declarations in JavaScript depends on whether the code is run in strict mode or not. It would be problematic if esbuild preserved nested function declarations in its output because then the behavior would depend on whether the output was run in strict mode or not instead of respecting the strict mode behavior of the original source code. To avoid this, esbuild transforms nested function declarations to preserve the intended behavior of the original source code regardless of whether the output is run in strict mode or not:

  // Original code
  if (true) {
    function foo() {}
    console.log(!!foo)
    foo = null
    console.log(!!foo)
  }
  console.log(!!foo)
  // Transformed code
  if (true) {
  let foo2 = function() {
  };
  

... (truncated)

Sourced from esbuild's changelog.

0.16.12

• Loader defaults to js for extensionless files (#2776)

  Certain packages contain files without an extension. For example, the yargs package contains the file yargs/yargs which has no extension. Node, Webpack, and Parcel can all understand code that imports yargs/yargs because they assume that the file is JavaScript. However, esbuild was previously unable to understand this code because it relies on the file extension to tell it how to interpret the file. With this release, esbuild will now assume files without an extension are JavaScript files. This can be customized by setting the loader for "" (the empty string, representing files without an extension) to another loader. For example, if you want files without an extension to be treated as CSS instead, you can do that like this:

  • CLI:

    esbuild --bundle --loader:=css
    

  • JS:

    esbuild.build({
      bundle: true,
      loader: { '': 'css' },
    })
    

  • Go:

    api.Build(api.BuildOptions{
      Bundle: true,
      Loader: map[string]api.Loader{"": api.LoaderCSS},
    })
    

  In addition, the "type" field in package.json files now only applies to files with an explicit .js, .jsx, .ts, or .tsx extension. Previously it was incorrectly applied by esbuild to all files that had an extension other than .mjs, .mts, .cjs, or .cts including extensionless files. So for example an extensionless file in a "type": "module" package is now treated as CommonJS instead of ESM.

0.16.11

• Avoid a syntax error in the presence of direct eval (#2761)

  The behavior of nested function declarations in JavaScript depends on whether the code is run in strict mode or not. It would be problematic if esbuild preserved nested function declarations in its output because then the behavior would depend on whether the output was run in strict mode or not instead of respecting the strict mode behavior of the original source code. To avoid this, esbuild transforms nested function declarations to preserve the intended behavior of the original source code regardless of whether the output is run in strict mode or not:

  // Original code
  if (true) {
    function foo() {}
    console.log(!!foo)
    foo = null
    console.log(!!foo)
  }
  console.log(!!foo)
  // Transformed code
  if (true) {
  

... (truncated)

• ddda86e publish 0.16.12 to npm
• ffe1c5b limit type in package.json to .js and friends
• 466473b fix #2776: assume extensionless files are js
• f42ca4a allow loaders for extensionless files
• 1755592 publish 0.16.11 to npm
• ba6246a fix #2773: eval dependency symlinks instead of reading symlink target (#2774)
• cf8ea74 Fix typo in js_parser_lower.go (#2771)
• 0a60afe additional test coverage
• 46347f7 fix #2761: avoid syntax error with direct eval
• c94ad6c explicit pre-release version error (#2766, #2760)
• 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.11

• Avoid a syntax error in the presence of direct eval (#2761)

  The behavior of nested function declarations in JavaScript depends on whether the code is run in strict mode or not. It would be problematic if esbuild preserved nested function declarations in its output because then the behavior would depend on whether the output was run in strict mode or not instead of respecting the strict mode behavior of the original source code. To avoid this, esbuild transforms nested function declarations to preserve the intended behavior of the original source code regardless of whether the output is run in strict mode or not:

  // Original code
  if (true) {
    function foo() {}
    console.log(!!foo)
    foo = null
    console.log(!!foo)
  }
  console.log(!!foo)
  // Transformed code
  if (true) {
  let foo2 = function() {
  };
  var foo = foo2;
  console.log(!!foo2);
  foo2 = null;
  console.log(!!foo2);
  }
  console.log(!!foo);
  

  In the above example, the original code should print true false true because it's not run in strict mode (it doesn't contain "use strict" and is not an ES module). The code that esbuild generates has been transformed such that it prints true false true regardless of whether it's run in strict mode or not.

  However, this transformation is impossible if the code contains direct eval because direct eval "poisons" all containing scopes by preventing anything in those scopes from being renamed. That prevents esbuild from splitting up accesses to foo into two separate variables with different names. Previously esbuild still did this transformation but with two variables both named foo, which is a syntax error. With this release esbuild will now skip doing this transformation when direct eval is present to avoid generating code with a syntax error. This means that the generated code may no longer behave as intended since the behavior depends on the run-time strict mode setting instead of the strict mode setting present in the original source code. To fix this problem, you will need to remove the use of direct eval.

• Fix a bundling scenario involving multiple symlinks (#2773, #2774)

  This release contains a fix for a bundling scenario involving an import path where multiple path segments are symlinks. Previously esbuild was unable to resolve certain import paths in this scenario, but these import paths should now work starting with this release. This fix was contributed by @​onebytegone.

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,
  

... (truncated)

Sourced from esbuild's changelog.

0.16.11

• Avoid a syntax error in the presence of direct eval (#2761)

  The behavior of nested function declarations in JavaScript depends on whether the code is run in strict mode or not. It would be problematic if esbuild preserved nested function declarations in its output because then the behavior would depend on whether the output was run in strict mode or not instead of respecting the strict mode behavior of the original source code. To avoid this, esbuild transforms nested function declarations to preserve the intended behavior of the original source code regardless of whether the output is run in strict mode or not:

  // Original code
  if (true) {
    function foo() {}
    console.log(!!foo)
    foo = null
    console.log(!!foo)
  }
  console.log(!!foo)
  // Transformed code
  if (true) {
  let foo2 = function() {
  };
  var foo = foo2;
  console.log(!!foo2);
  foo2 = null;
  console.log(!!foo2);
  }
  console.log(!!foo);
  

  In the above example, the original code should print true false true because it's not run in strict mode (it doesn't contain "use strict" and is not an ES module). The code that esbuild generates has been transformed such that it prints true false true regardless of whether it's run in strict mode or not.

  However, this transformation is impossible if the code contains direct eval because direct eval "poisons" all containing scopes by preventing anything in those scopes from being renamed. That prevents esbuild from splitting up accesses to foo into two separate variables with different names. Previously esbuild still did this transformation but with two variables both named foo, which is a syntax error. With this release esbuild will now skip doing this transformation when direct eval is present to avoid generating code with a syntax error. This means that the generated code may no longer behave as intended since the behavior depends on the run-time strict mode setting instead of the strict mode setting present in the original source code. To fix this problem, you will need to remove the use of direct eval.

• Fix a bundling scenario involving multiple symlinks (#2773, #2774)

  This release contains a fix for a bundling scenario involving an import path where multiple path segments are symlinks. Previously esbuild was unable to resolve certain import paths in this scenario, but these import paths should now work starting with this release. This fix was contributed by @​onebytegone.

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
  

... (truncated)

• 1755592 publish 0.16.11 to npm
• ba6246a fix #2773: eval dependency symlinks instead of reading symlink target (#2774)
• cf8ea74 Fix typo in js_parser_lower.go (#2771)
• 0a60afe additional test coverage
• 46347f7 fix #2761: avoid syntax error with direct eval
• c94ad6c explicit pre-release version error (#2766, #2760)
• 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
• 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)

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

• Include file loader strings in metafile imports (#2731)

  Bundling a file with the file loader copies that file to the output directory and imports a module with the path to the copied file in the default export. Previously when bundling with the file loader, there was no reference in the metafile from the JavaScript file containing the path string to the copied file. With this release, there will now be a reference in the metafile in the imports array with the kind file-loader:

   {
     ...
     "outputs": {
       "out/image-55CCFTCE.svg": {
         ...
       },
       "out/entry.js": {
         "imports": [
  +        {
  +          "path": "out/image-55CCFTCE.svg",
  +          "kind": "file-loader"
  +        }
         ],
         ...
       }
     }
   }
  

• Fix byte counts in metafile regarding references to other output files (#2071)

  Previously files that contained references to other output files had slightly incorrect metadata for the byte counts of input files which contributed to that output file. So for example if app.js imports image.png using the file loader and esbuild generates out.js and image-LSAMBFUD.png, the metadata for how many bytes of out.js are from app.js was slightly off (the metadata for the byte count of out.js was still correct). The reason is because esbuild substitutes the final paths for references between output files toward the end of the build to handle cyclic references, and the byte counts needed to be adjusted as well during the path substitution. This release fixes these byte counts (specifically the bytesInOutput values).

• The alias feature now strips a trailing slash (#2730)

  People sometimes add a trailing slash to the name of one of node's built-in modules to force node to import from the file system instead of importing the built-in module. For example, importing util imports node's built-in module called util but importing util/ tries to find a package called util on the file system. Previously attempting to use esbuild's package alias feature to replace imports to util with a specific file would fail because the file path would also gain a trailing slash (e.g. mapping util to ./file.js turned util/ into ./file.js/). With this release, esbuild will now omit the path suffix if it's a single trailing slash, which should now allow you to successfully apply aliases to these import paths.

Sourced from esbuild's changelog.

0.16.7

• Include file loader strings in metafile imports (#2731)

  Bundling a file with the file loader copies that file to the output directory and imports a module with the path to the copied file in the default export. Previously when bundling with the file loader, there was no reference in the metafile from the JavaScript file containing the path string to the copied file. With this release, there will now be a reference in the metafile in the imports array with the kind file-loader:

   {
     ...
     "outputs": {
       "out/image-55CCFTCE.svg": {
         ...
       },
       "out/entry.js": {
         "imports": [
  +        {
  +          "path": "out/image-55CCFTCE.svg",
  +          "kind": "file-loader"
  +        }
         ],
         ...
       }
     }
   }
  

• Fix byte counts in metafile regarding references to other output files (#2071)

  Previously files that contained references to other output files had slightly incorrect metadata for the byte counts of input files which contributed to that output file. So for example if app.js imports image.png using the file loader and esbuild generates out.js and image-LSAMBFUD.png, the metadata for how many bytes of out.js are from app.js was slightly off (the metadata for the byte count of out.js was still correct). The reason is because esbuild substitutes the final paths for references between output files toward the end of the build to handle cyclic references, and the byte counts needed to be adjusted as well during the path substitution. This release fixes these byte counts (specifically the bytesInOutput values).

• The alias feature now strips a trailing slash (#2730)

  People sometimes add a trailing slash to the name of one of node's built-in modules to force node to import from the file system instead of importing the built-in module. For example, importing util imports node's built-in module called util but importing util/ tries to find a package called util on the file system. Previously attempting to use esbuild's package alias feature to replace imports to util with a specific file would fail because the file path would also gain a trailing slash (e.g. mapping util to ./file.js turned util/ into ./file.js/). With this release, esbuild will now omit the path suffix if it's a single trailing slash, which should now allow you to successfully apply aliases to these import paths.

• be16d81 publish 0.16.7 to npm
• 0c872cd additional linker comments
• a375b37 fix #2071: remap bytesInOutput for substitutions
• 0e12657 fix bugs due to lack of file-private vars in go
• cd3fdcc move chunks array onto linker
• eb0e118 metafile coverage for paths between output files
• 7bf440d fix #2730: alias now strips a trailing slash
• b0a82d3 fix #2731: put file loader strings in metafile
• 70c5729 a small js minification improvement
• See full diff 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.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.

v0.16.0

This release deliberately contains backwards-incompatible changes. To avoid automatically picking up releases like this, you should either be pinning the exact version of esbuild in your package.json file (recommended) or be using a version range syntax that only accepts patch upgrades such as ^0.15.0 or ~0.15.0. See npm's documentation about semver for more information.

• Move all binary executable packages to the @esbuild/ scope

  Binary package executables for esbuild are published as individual packages separate from the main esbuild package so you only have to download the relevant one for the current platform when you install esbuild. This release moves all of these packages under the @esbuild/ scope to avoid collisions with 3rd-party packages. It also changes them to a consistent naming scheme that uses the os and cpu names from node.

  The package name changes are as follows:

... (truncated)

Sourced from esbuild's changelog.

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.

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

0.16.0

This release deliberately contains backwards-incompatible changes. To avoid automatically picking up releases like this, you should either be pinning the exact version of esbuild in your package.json file (recommended) or be using a version range syntax that only accepts patch upgrades such as ^0.15.0 or ~0.15.0. See npm's documentation about semver for more information.

• Move all binary executable packages to the @esbuild/ scope

  Binary package executables for esbuild are published as individual packages separate from the main esbuild package so you only have to download the relevant one for the current platform when you install esbuild. This release moves all of these packages under the @esbuild/ scope to avoid collisions with 3rd-party packages. It also changes them to a consistent naming scheme that uses the os and cpu names from node.

... (truncated)

• 0829d74 publish 0.16.2 to npm
• 7b45a3b fix #2718: transform keeps process.env.NODE_ENV
• a4d7d97 fix #2723: skip import.meta warnings in packages
• c189b30 fix #2722: write ^0.15.0 in the release notes
• 9493e3b fix #2719: avoid define creating syntax errors
• a2a2dd0 fix #2720: adapt npm i --no-optional to scopes
• 1ae3ca6 fix #917: document my basic development workflow
• 3b62a36 publish 0.16.1 to npm
• 07f8eeb hotfix: re-allow copy with json import assertion
• 219ffc6 fix JSXMode => JSX for the Go transform API
• 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.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.

v0.16.0

This release deliberately contains backwards-incompatible changes. To avoid automatically picking up releases like this, you should either be pinning the exact version of esbuild in your package.json file (recommended) or be using a version range syntax that only accepts patch upgrades such as ~0.15.0. See npm's documentation about semver for more information.

• Move all binary executable packages to the @esbuild/ scope

  Binary package executables for esbuild are published as individual packages separate from the main esbuild package so you only have to download the relevant one for the current platform when you install esbuild. This release moves all of these packages under the @esbuild/ scope to avoid collisions with 3rd-party packages. It also changes them to a consistent naming scheme that uses the os and cpu names from node.

  The package name changes are as follows:

  • @esbuild/linux-loong64 => @esbuild/linux-loong64 (no change)
  • esbuild-android-64 => @esbuild/android-x64
  • esbuild-android-arm64 => @esbuild/android-arm64
  • esbuild-darwin-64 => @esbuild/darwin-x64
  • esbuild-darwin-arm64 => @esbuild/darwin-arm64
  • esbuild-freebsd-64 => @esbuild/freebsd-x64
  • esbuild-freebsd-arm64 => @esbuild/freebsd-arm64
  • esbuild-linux-32 => @esbuild/linux-ia32
  • esbuild-linux-64 => @esbuild/linux-x64
  • esbuild-linux-arm => @esbuild/linux-arm
  • esbuild-linux-arm64 => @esbuild/linux-arm64
  • esbuild-linux-mips64le => @esbuild/linux-mips64el
  • esbuild-linux-ppc64le => @esbuild/linux-ppc64
  • esbuild-linux-riscv64 => @esbuild/linux-riscv64
  • esbuild-linux-s390x => @esbuild/linux-s390x
  • esbuild-netbsd-64 => @esbuild/netbsd-x64
  • esbuild-openbsd-64 => @esbuild/openbsd-x64
  • esbuild-sunos-64 => @esbuild/sunos-x64
  • esbuild-wasm => esbuild-wasm (no change)
  • esbuild-windows-32 => @esbuild/win32-ia32
  • esbuild-windows-64 => @esbuild/win32-x64
  • esbuild-windows-arm64 => @esbuild/win32-arm64
  • esbuild => esbuild (no change)

  Normal usage of the esbuild and esbuild-wasm packages should not be affected. These name changes should only affect tools that hard-coded the individual binary executable package names into custom esbuild downloader scripts.

  This change was not made with performance in mind. But as a bonus, installing esbuild with npm may potentially happen faster now. This is because npm's package installation protocol is inefficient: it always downloads metadata for all past versions of each package even when it only needs metadata about a single version. This makes npm package downloads O(n) in the number of published versions, which penalizes packages like esbuild that are updated regularly. Since most of esbuild's package names have now changed, npm will now need to download much less data when installing esbuild (8.72mb of package manifests before this change → 0.06mb of package manifests after this change). However, this is only a temporary improvement. Installing esbuild will gradually get slower again as further versions of esbuild are published.

• Publish a shell script that downloads esbuild directly

  In addition to all of the existing ways to install esbuild, you can now also download esbuild directly like this:

  curl -fsSL https://esbuild.github.io/dl/latest | sh
  

... (truncated)

Sourced from esbuild's changelog.

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

0.16.0

This release deliberately contains backwards-incompatible changes. To avoid automatically picking up releases like this, you should either be pinning the exact version of esbuild in your package.json file (recommended) or be using a version range syntax that only accepts patch upgrades such as ~0.15.0. See npm's documentation about semver for more information.

• Move all binary executable packages to the @esbuild/ scope

  Binary package executables for esbuild are published as individual packages separate from the main esbuild package so you only have to download the relevant one for the current platform when you install esbuild. This release moves all of these packages under the @esbuild/ scope to avoid collisions with 3rd-party packages. It also changes them to a consistent naming scheme that uses the os and cpu names from node.

  The package name changes are as follows:

  • @esbuild/linux-loong64 => @esbuild/linux-loong64 (no change)
  • esbuild-android-64 => @esbuild/android-x64
  • esbuild-android-arm64 => @esbuild/android-arm64
  • esbuild-darwin-64 => @esbuild/darwin-x64
  • esbuild-darwin-arm64 => @esbuild/darwin-arm64
  • esbuild-freebsd-64 => @esbuild/freebsd-x64
  • esbuild-freebsd-arm64 => @esbuild/freebsd-arm64
  • esbuild-linux-32 => @esbuild/linux-ia32
  • esbuild-linux-64 => @esbuild/linux-x64
  • esbuild-linux-arm => @esbuild/linux-arm
  • esbuild-linux-arm64 => @esbuild/linux-arm64
  • esbuild-linux-mips64le => @esbuild/linux-mips64el
  • esbuild-linux-ppc64le => @esbuild/linux-ppc64
  • esbuild-linux-riscv64 => @esbuild/linux-riscv64
  • esbuild-linux-s390x => @esbuild/linux-s390x
  • esbuild-netbsd-64 => @esbuild/netbsd-x64
  • esbuild-openbsd-64 => @esbuild/openbsd-x64
  • esbuild-sunos-64 => @esbuild/sunos-x64
  • esbuild-wasm => esbuild-wasm (no change)
  • esbuild-windows-32 => @esbuild/win32-ia32
  • esbuild-windows-64 => @esbuild/win32-x64
  • esbuild-windows-arm64 => @esbuild/win32-arm64
  • esbuild => esbuild (no change)

  Normal usage of the esbuild and esbuild-wasm packages should not be affected. These name changes should only affect tools that hard-coded the individual binary executable package names into custom esbuild downloader scripts.

  This change was not made with performance in mind. But as a bonus, installing esbuild with npm may potentially happen faster now. This is because npm's package installation protocol is inefficient: it always downloads metadata for all past versions of each package even when it only needs metadata about a single version. This makes npm package downloads O(n) in the number of published versions, which penalizes packages like esbuild that are updated regularly. Since most of esbuild's package names have now changed, npm will now need to download much less data when installing esbuild (8.72mb of package manifests before this change → 0.06mb of package manifests after this change). However, this is only a temporary improvement. Installing esbuild will gradually get slower again as further versions of esbuild are published.

• Publish a shell script that downloads esbuild directly

  In addition to all of the existing ways to install esbuild, you can now also download esbuild directly like this:

... (truncated)

• 3b62a36 publish 0.16.1 to npm
• 07f8eeb hotfix: re-allow copy with json import assertion
• 219ffc6 fix JSXMode => JSX for the Go transform API
• 6c8d15d publish 0.16.0 to npm
• 895f50c fix #1843: generate shorter data urls if possible
• 5abe071 fix #2417: add the module condition by default
• 328ce12 fix #2649: allow disabling escaping of \</script>
• 0228284 discard legal comments by default
• c3b0890 fix #714: remove the webassembly _exit(0) hack
• 055f9e3 add a shell script that downloads esbuild directly
• 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.3

• Change the Yarn PnP manifest to a singleton (#2463)

  Previously esbuild searched for the Yarn PnP manifest in the parent directories of each file. But with Yarn's enableGlobalCache setting it's possible to configure Yarn PnP's implementation to reach outside of the directory subtree containing the Yarn PnP manifest. This was causing esbuild to fail to bundle projects with the enableGlobalCache setting enabled.

  To handle this case, esbuild will now only search for the Yarn PnP manifest in the current working directory of the esbuild process. If you're using esbuild's CLI, this means you will now have to cd into the appropriate directory first. If you're using esbuild's API, you can override esbuild's value for the current working directory with the absWorkingDir API option.

• Fix Yarn PnP resolution failures due to backslashes in paths on Windows (#2462)

  Previously dependencies of a Yarn PnP virtual dependency failed to resolve on Windows. This was because Windows uses \ instead of / as a path separator, and the path manipulation algorithms used for Yarn PnP expected /. This release converts \ into / in Windows paths, which fixes this issue.

• Fix sideEffects patterns containing slashes on Windows (#2465)

  The sideEffects field in package.json lets you specify an array of patterns to mark which files have side effects (which causes all other files to be considered to not have side effects by exclusion). That looks like this:

  "sideEffects": [
    "**/index.js",
    "**/index.prod.js"
  ]
  

  However, the presence of the / character in the pattern meant that the pattern failed to match Windows-style paths, which broke sideEffects on Windows in this case. This release fixes this problem by adding additional code to handle Windows-style paths.

v0.15.2

• Fix Yarn PnP issue with packages containing index.js (#2455, #2461)

  Yarn PnP's tests require the resolved paths to end in /. That's not how the rest of esbuild's internals work, however, and doing this messed up esbuild's node module path resolution regarding automatically-detected index.js files. Previously packages that relied on implicit index.js resolution rules didn't work with esbuild under Yarn PnP. Removing this slash has fixed esbuild's path resolution behavior regarding index.js, which should now the same both with and without Yarn PnP.

• Fix Yarn PnP support for extends in tsconfig.json (#2456)

  Previously using extends in tsconfig.json with a path in a Yarn PnP package didn't work. This is because the process of setting up package path resolution rules requires parsing tsconfig.json files (due to the baseUrl and paths features) and resolving extends to a package path requires package path resolution rules to already be set up, which is a circular dependency. This cycle is broken by using special rules for extends in tsconfig.json that bypasses esbuild's normal package path resolution process. This is why using extends with a Yarn PnP package didn't automatically work. With this release, these special rules have been modified to check for a Yarn PnP manifest so this case should work now.

• Fix Yarn PnP support in esbuild-wasm (#2458)

  When running esbuild via WebAssembly, Yarn PnP support previously failed because Go's file system internals return EINVAL when trying to read a .zip file as a directory when run with WebAssembly. This was unexpected because Go's file system internals return ENOTDIR for this case on native. This release updates esbuild to treat EINVAL like ENOTDIR in this case, which fixes using esbuild-wasm to bundle a Yarn PnP project.

  Note that to be able to use esbuild-wasm for Yarn PnP successfully, you currently have to run it using node instead of yarn node. This is because the file system shim that Yarn overwrites node's native file system API with currently generates invalid file descriptors with negative values when inside a .zip file. This prevents esbuild from working correctly because Go's file system internals don't expect syscalls that succeed without an error to return an invalid file descriptor. Yarn is working on fixing their use of invalid file descriptors.

Sourced from esbuild's changelog.

0.15.3

• Change the Yarn PnP manifest to a singleton (#2463)

  Previously esbuild searched for the Yarn PnP manifest in the parent directories of each file. But with Yarn's enableGlobalCache setting it's possible to configure Yarn PnP's implementation to reach outside of the directory subtree containing the Yarn PnP manifest. This was causing esbuild to fail to bundle projects with the enableGlobalCache setting enabled.

  To handle this case, esbuild will now only search for the Yarn PnP manifest in the current working directory of the esbuild process. If you're using esbuild's CLI, this means you will now have to cd into the appropriate directory first. If you're using esbuild's API, you can override esbuild's value for the current working directory with the absWorkingDir API option.

• Fix Yarn PnP resolution failures due to backslashes in paths on Windows (#2462)

  Previously dependencies of a Yarn PnP virtual dependency failed to resolve on Windows. This was because Windows uses \ instead of / as a path separator, and the path manipulation algorithms used for Yarn PnP expected /. This release converts \ into / in Windows paths, which fixes this issue.

• Fix sideEffects patterns containing slashes on Windows (#2465)

  The sideEffects field in package.json lets you specify an array of patterns to mark which files have side effects (which causes all other files to be considered to not have side effects by exclusion). That looks like this:

  "sideEffects": [
    "**/index.js",
    "**/index.prod.js"
  ]
  

  However, the presence of the / character in the pattern meant that the pattern failed to match Windows-style paths, which broke sideEffects on Windows in this case. This release fixes this problem by adding additional code to handle Windows-style paths.

0.15.2

• Fix Yarn PnP issue with packages containing index.js (#2455, #2461)

  Yarn PnP's tests require the resolved paths to end in /. That's not how the rest of esbuild's internals work, however, and doing this messed up esbuild's node module path resolution regarding automatically-detected index.js files. Previously packages that relied on implicit index.js resolution rules didn't work with esbuild under Yarn PnP. Removing this slash has fixed esbuild's path resolution behavior regarding index.js, which should now the same both with and without Yarn PnP.

• Fix Yarn PnP support for extends in tsconfig.json (#2456)

  Previously using extends in tsconfig.json with a path in a Yarn PnP package didn't work. This is because the process of setting up package path resolution rules requires parsing tsconfig.json files (due to the baseUrl and paths features) and resolving extends to a package path requires package path resolution rules to already be set up, which is a circular dependency. This cycle is broken by using special rules for extends in tsconfig.json that bypasses esbuild's normal package path resolution process. This is why using extends with a Yarn PnP package didn't automatically work. With this release, these special rules have been modified to check for a Yarn PnP manifest so this case should work now.

• Fix Yarn PnP support in esbuild-wasm (#2458)

  When running esbuild via WebAssembly, Yarn PnP support previously failed because Go's file system internals return EINVAL when trying to read a .zip file as a directory when run with WebAssembly. This was unexpected because Go's file system internals return ENOTDIR for this case on native. This release updates esbuild to treat EINVAL like ENOTDIR in this case, which fixes using esbuild-wasm to bundle a Yarn PnP project.

  Note that to be able to use esbuild-wasm for Yarn PnP successfully, you currently have to run it using node instead of yarn node. This is because the file system shim that Yarn overwrites node's native file system API with currently generates invalid file descriptors with negative values when inside a .zip file. This prevents esbuild from working correctly because Go's file system internals don't expect syscalls that succeed without an error to return an invalid file descriptor. Yarn is working on fixing their use of invalid file descriptors.

• eeb2509 publish 0.15.3 to npm
• 8a71011 pnp: remove unused dependencyTreeRoots data
• 44a7a61 fix #2463: change yarn pnp manifest to a singleton
• 6fd8736 fix #2465: handle windows paths and sideEffects
• 9f0699f unit tests: run using both windows and unix paths
• 1f7273c fix #2462: convert \ to / in windows paths
• e6fa739 publish 0.15.2 to npm
• 9b40267 fix #2455: strip / to fix index.js edge case
• 4e68c27 fix #2456: extends in tsconfig.json with pnp
• 201c1f6 release notes for the previous commit (#2458)
• 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 @​actions/core's changelog.

1.9.1

• Randomize delimiter when calling core.exportVariable

1.9.0

• Added toPosixPath, toWin32Path and toPlatformPath utilities #1102

• See full diff 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.14.54

• Fix optimizations for calls containing spread arguments (#2445)

  This release fixes the handling of spread arguments in the optimization of /* @__PURE__ */ comments, empty functions, and identity functions:

  // Original code
  function empty() {}
  function identity(x) { return x }
  /* @__PURE__ */ a(...x)
  /* @__PURE__ */ new b(...x)
  empty(...x)
  identity(...x)
  // Old output (with --minify --tree-shaking=true)
  ...x;...x;...x;...x;
  // New output (with --minify --tree-shaking=true)
  function identity(n){return n}[...x];[...x];[...x];identity(...x);
  

  Previously esbuild assumed arguments with side effects could be directly inlined. This is almost always true except for spread arguments, which are not syntactically valid on their own and which have the side effect of causing iteration, which might have further side effects. Now esbuild will wrap these elements in an unused array so that they are syntactically valid and so that the iteration side effects are preserved.

v0.14.53

This release fixes a minor issue with the previous release: I had to rename the package esbuild-linux-loong64 to @esbuild/linux-loong64 in the contributed PR because someone registered the package name before I could claim it, and I missed a spot. Hopefully everything is working after this release. I plan to change all platform-specific package names to use the @esbuild/ scope at some point to avoid this problem in the future.

v0.14.52

• Allow binary data as input to the JS transform and build APIs (#2424)

  Previously esbuild's transform and build APIs could only take a string. However, some people want to use esbuild to convert binary data to base64 text. This is problematic because JavaScript strings represent UTF-16 text and esbuild internally operates on arrays of bytes, so all strings coming from JavaScript undergo UTF-16 to UTF-8 conversion before use. This meant that using esbuild in this way was doing base64 encoding of the UTF-8 encoding of the text, which was undesired.

  With this release, esbuild now accepts Uint8Array in addition to string as an input format for the transform and build APIs. Now you can use esbuild to convert binary data to base64 text:

  // Original code
  import esbuild from 'esbuild'
  console.log([
    (await esbuild.transform('\xFF', { loader: 'base64' })).code,
    (await esbuild.build({ stdin: { contents: '\xFF', loader: 'base64' }, write: false })).outputFiles[0].text,
  ])
  console.log([
    (await esbuild.transform(new Uint8Array([0xFF]), { loader: 'base64' })).code,
    (await esbuild.build({ stdin: { contents: new Uint8Array([0xFF]), loader: 'base64' }, write: false })).outputFiles[0].text,
  ])
  // Old output
  [ 'module.exports = "w78=";\n', 'module.exports = "w78=";\n' ]
  /* ERROR: The input to "transform" must be a string */
  // New output
  

... (truncated)

Sourced from esbuild's changelog.

0.14.54

• Fix optimizations for calls containing spread arguments (#2445)

  This release fixes the handling of spread arguments in the optimization of /* @__PURE__ */ comments, empty functions, and identity functions:

  // Original code
  function empty() {}
  function identity(x) { return x }
  /* @__PURE__ */ a(...x)
  /* @__PURE__ */ new b(...x)
  empty(...x)
  identity(...x)
  // Old output (with --minify --tree-shaking=true)
  ...x;...x;...x;...x;
  // New output (with --minify --tree-shaking=true)
  function identity(n){return n}[...x];[...x];[...x];identity(...x);
  

  Previously esbuild assumed arguments with side effects could be directly inlined. This is almost always true except for spread arguments, which are not syntactically valid on their own and which have the side effect of causing iteration, which might have further side effects. Now esbuild will wrap these elements in an unused array so that they are syntactically valid and so that the iteration side effects are preserved.

0.14.53

This release fixes a minor issue with the previous release: I had to rename the package esbuild-linux-loong64 to @esbuild/linux-loong64 in the contributed PR because someone registered the package name before I could claim it, and I missed a spot. Hopefully everything is working after this release. I plan to change all platform-specific package names to use the @esbuild/ scope at some point to avoid this problem in the future.

0.14.52

• Allow binary data as input to the JS transform and build APIs (#2424)

  Previously esbuild's transform and build APIs could only take a string. However, some people want to use esbuild to convert binary data to base64 text. This is problematic because JavaScript strings represent UTF-16 text and esbuild internally operates on arrays of bytes, so all strings coming from JavaScript undergo UTF-16 to UTF-8 conversion before use. This meant that using esbuild in this way was doing base64 encoding of the UTF-8 encoding of the text, which was undesired.

  With this release, esbuild now accepts Uint8Array in addition to string as an input format for the transform and build APIs. Now you can use esbuild to convert binary data to base64 text:

  // Original code
  import esbuild from 'esbuild'
  console.log([
    (await esbuild.transform('\xFF', { loader: 'base64' })).code,
    (await esbuild.build({ stdin: { contents: '\xFF', loader: 'base64' }, write: false })).outputFiles[0].text,
  ])
  console.log([
    (await esbuild.transform(new Uint8Array([0xFF]), { loader: 'base64' })).code,
    (await esbuild.build({ stdin: { contents: new Uint8Array([0xFF]), loader: 'base64' }, write: false })).outputFiles[0].text,
  ])
  // Old output
  [ 'module.exports = "w78=";\n', 'module.exports = "w78=";\n' ]
  

... (truncated)

• 04ef75f publish 0.14.54 to npm
• 20878ce fix #2445: fixes for spread arguments and --minify
• b2b5a60 ci: move uglify into slow tests
• b9cae14 ci: clarify some test labels
• fe9b711 attempt to speed up ci: isolate rollup tests
• 4e65c73 publish 0.14.53 to npm
• adbb475 missed two esbuild-linux-loong64 names
• 39eccb8 publish 0.14.52 to npm
• d6cf390 Support Loongarch LE architecture (#2373)
• 296870e workarounds for bad go comment formatting behavior
• 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.14.53

This release fixes a minor issue with the previous release: I had to rename the package esbuild-linux-loong64 to @esbuild/linux-loong64 in the contributed PR because someone registered the package name before I could claim it, and I missed a spot. Hopefully everything is working after this release. I plan to change all platform-specific package names to use the @esbuild/ scope at some point to avoid this problem in the future.

v0.14.52

• Allow binary data as input to the JS transform and build APIs (#2424)

  Previously esbuild's transform and build APIs could only take a string. However, some people want to use esbuild to convert binary data to base64 text. This is problematic because JavaScript strings represent UTF-16 text and esbuild internally operates on arrays of bytes, so all strings coming from JavaScript undergo UTF-16 to UTF-8 conversion before use. This meant that using esbuild in this way was doing base64 encoding of the UTF-8 encoding of the text, which was undesired.

  With this release, esbuild now accepts Uint8Array in addition to string as an input format for the transform and build APIs. Now you can use esbuild to convert binary data to base64 text:

  // Original code
  import esbuild from 'esbuild'
  console.log([
    (await esbuild.transform('\xFF', { loader: 'base64' })).code,
    (await esbuild.build({ stdin: { contents: '\xFF', loader: 'base64' }, write: false })).outputFiles[0].text,
  ])
  console.log([
    (await esbuild.transform(new Uint8Array([0xFF]), { loader: 'base64' })).code,
    (await esbuild.build({ stdin: { contents: new Uint8Array([0xFF]), loader: 'base64' }, write: false })).outputFiles[0].text,
  ])
  // Old output
  [ 'module.exports = "w78=";\n', 'module.exports = "w78=";\n' ]
  /* ERROR: The input to "transform" must be a string */
  // New output
  [ 'module.exports = "w78=";\n', 'module.exports = "w78=";\n' ]
  [ 'module.exports = "/w==";\n', 'module.exports = "/w==";\n' ]
  

• Update the getter for text in build results (#2423)

  Output files in build results returned from esbuild's JavaScript API have both a contents and a text property to return the contents of the output file. The contents property is a binary UTF-8 Uint8Array and the text property is a JavaScript UTF-16 string. The text property is a getter that does the UTF-8 to UTF-16 conversion only if it's needed for better performance.

  Previously if you mutate the build results object, you had to overwrite both contents and text since the value returned from the text getter is the original text returned by esbuild. Some people find this confusing so with this release, the getter for text has been updated to do the UTF-8 to UTF-16 conversion on the current value of the contents property instead of the original value.

• Publish builds for Linux LoongArch 64-bit (#1804, #2373)

  This release upgrades to Go 1.19, which now includes support for LoongArch 64-bit processors. LoongArch 64-bit builds of esbuild will now be published to npm, which means that in theory they can now be installed with npm install esbuild. This was contributed by @​beyond-1234.

v0.14.51

• Add support for React 17's automatic JSX transform (#334, #718, #1172, #2318, #2349)

  This adds support for the new "automatic" JSX runtime from React 17+ to esbuild for both the build and transform APIs.

  New CLI flags and API options:

  • --jsx, jsx — Set this to "automatic" to opt in to this new transform
  • --jsx-dev, jsxDev — Toggles development mode for the automatic runtime
  • --jsx-import-source, jsxImportSource — Overrides the root import for runtime functions (default "react")

... (truncated)

Sourced from esbuild's changelog.

0.14.53

This release fixes a minor issue with the previous release: I had to rename the package esbuild-linux-loong64 to @esbuild/linux-loong64 in the contributed PR because someone registered the package name before I could claim it, and I missed a spot. Hopefully everything is working after this release. I plan to change all platform-specific package names to use the @esbuild/ scope at some point to avoid this problem in the future.

0.14.52

• Allow binary data as input to the JS transform and build APIs (#2424)

  Previously esbuild's transform and build APIs could only take a string. However, some people want to use esbuild to convert binary data to base64 text. This is problematic because JavaScript strings represent UTF-16 text and esbuild internally operates on arrays of bytes, so all strings coming from JavaScript undergo UTF-16 to UTF-8 conversion before use. This meant that using esbuild in this way was doing base64 encoding of the UTF-8 encoding of the text, which was undesired.

  With this release, esbuild now accepts Uint8Array in addition to string as an input format for the transform and build APIs. Now you can use esbuild to convert binary data to base64 text:

  // Original code
  import esbuild from 'esbuild'
  console.log([
    (await esbuild.transform('\xFF', { loader: 'base64' })).code,
    (await esbuild.build({ stdin: { contents: '\xFF', loader: 'base64' }, write: false })).outputFiles[0].text,
  ])
  console.log([
    (await esbuild.transform(new Uint8Array([0xFF]), { loader: 'base64' })).code,
    (await esbuild.build({ stdin: { contents: new Uint8Array([0xFF]), loader: 'base64' }, write: false })).outputFiles[0].text,
  ])
  // Old output
  [ 'module.exports = "w78=";\n', 'module.exports = "w78=";\n' ]
  /* ERROR: The input to "transform" must be a string */
  // New output
  [ 'module.exports = "w78=";\n', 'module.exports = "w78=";\n' ]
  [ 'module.exports = "/w==";\n', 'module.exports = "/w==";\n' ]
  

• Update the getter for text in build results (#2423)

  Output files in build results returned from esbuild's JavaScript API have both a contents and a text property to return the contents of the output file. The contents property is a binary UTF-8 Uint8Array and the text property is a JavaScript UTF-16 string. The text property is a getter that does the UTF-8 to UTF-16 conversion only if it's needed for better performance.

  Previously if you mutate the build results object, you had to overwrite both contents and text since the value returned from the text getter is the original text returned by esbuild. Some people find this confusing so with this release, the getter for text has been updated to do the UTF-8 to UTF-16 conversion on the current value of the contents property instead of the original value.

• Publish builds for Linux LoongArch 64-bit (#1804, #2373)

  This release upgrades to Go 1.19, which now includes support for LoongArch 64-bit processors. LoongArch 64-bit builds of esbuild will now be published to npm, which means that in theory they can now be installed with npm install esbuild. This was contributed by @​beyond-1234.

0.14.51

• Add support for React 17's automatic JSX transform (#334, #718, #1172, #2318, #2349)

  This adds support for the new "automatic" JSX runtime from React 17+ to esbuild for both the build and transform APIs.

  New CLI flags and API options:

... (truncated)

• 4e65c73 publish 0.14.53 to npm
• adbb475 missed two esbuild-linux-loong64 names
• 39eccb8 publish 0.14.52 to npm
• d6cf390 Support Loongarch LE architecture (#2373)
• 296870e workarounds for bad go comment formatting behavior
• af0ab3e run the new go formatter, which mangles comments
• 21deb41 update go 1.18.4 => 1.19
• ea63c87 add a note about go 1.13 (#2431)
• 7bd4900 Revert "fix #2417: autmatically add module to conditions"
• 5e918f4 fix #2417: autmatically add module to conditions
• 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.13

• Publish a new bundle visualization tool

  While esbuild provides bundle metadata via the --metafile flag, previously esbuild left analysis of it completely up to third-party tools (well, outside of the rudimentary --analyze flag). However, the esbuild website now has a built-in bundle visualization tool:

  • https://esbuild.github.io/analyze/

  You can pass --metafile to esbuild to output bundle metadata, then upload that JSON file to this tool to visualize your bundle. This is helpful for answering questions such as:

  • Which packages are included in my bundle?
  • How did a specific file get included?
  • How small did a specific file compress to?
  • Was a specific file tree-shaken or not?

  I'm publishing this tool because I think esbuild should provide some answer to "how do I visualize my bundle" without requiring people to reach for third-party tools. At the moment the tool offers two types of visualizations: a radial "sunburst chart" and a linear "flame chart". They serve slightly different but overlapping use cases (e.g. the sunburst chart is more keyboard-accessible while the flame chart is easier with the mouse). This tool may continue to evolve over time.

• Fix --metafile and --mangle-cache with --watch (#1357)

  The CLI calls the Go API and then also writes out the metafile and/or mangle cache JSON files if those features are enabled. This extra step is necessary because these files are returned by the Go API as in-memory strings. However, this extra step accidentally didn't happen for all builds after the initial build when watch mode was enabled. This behavior used to work but it was broken in version 0.14.18 by the introduction of the mangle cache feature. This release fixes the combination of these features, so the metafile and mangle cache features should now work with watch mode. This behavior was only broken for the CLI, not for the JS or Go APIs.

• Add an original field to the metafile

  The metadata file JSON now has an additional field: each import in an input file now contains the pre-resolved path in the original field in addition to the post-resolved path in the path field. This means it's now possible to run certain additional analysis over your bundle. For example, you should be able to use this to detect when the same package subpath is represented multiple times in the bundle, either because multiple versions of a package were bundled or because a package is experiencing the dual-package hazard.

v0.16.12

• Loader defaults to js for extensionless files (#2776)

  Certain packages contain files without an extension. For example, the yargs package contains the file yargs/yargs which has no extension. Node, Webpack, and Parcel can all understand code that imports yargs/yargs because they assume that the file is JavaScript. However, esbuild was previously unable to understand this code because it relies on the file extension to tell it how to interpret the file. With this release, esbuild will now assume files without an extension are JavaScript files. This can be customized by setting the loader for "" (the empty string, representing files without an extension) to another loader. For example, if you want files without an extension to be treated as CSS instead, you can do that like this:

  • CLI:

    esbuild --bundle --loader:=css
    

  • JS:

    esbuild.build({
      bundle: true,
      loader: { '': 'css' },
    })
    

  • Go:

    api.Build(api.BuildOptions{
      Bundle: true,
      Loader: map[string]api.Loader{"": api.LoaderCSS},
    

... (truncated)

Sourced from esbuild's changelog.

0.16.13

• Publish a new bundle visualization tool

  While esbuild provides bundle metadata via the --metafile flag, previously esbuild left analysis of it completely up to third-party tools (well, outside of the rudimentary --analyze flag). However, the esbuild website now has a built-in bundle visualization tool:

  • https://esbuild.github.io/analyze/

  You can pass --metafile to esbuild to output bundle metadata, then upload that JSON file to this tool to visualize your bundle. This is helpful for answering questions such as:

  • Which packages are included in my bundle?
  • How did a specific file get included?
  • How small did a specific file compress to?
  • Was a specific file tree-shaken or not?

  I'm publishing this tool because I think esbuild should provide some answer to "how do I visualize my bundle" without requiring people to reach for third-party tools. At the moment the tool offers two types of visualizations: a radial "sunburst chart" and a linear "flame chart". They serve slightly different but overlapping use cases (e.g. the sunburst chart is more keyboard-accessible while the flame chart is easier with the mouse). This tool may continue to evolve over time.

• Fix --metafile and --mangle-cache with --watch (#1357)

  The CLI calls the Go API and then also writes out the metafile and/or mangle cache JSON files if those features are enabled. This extra step is necessary because these files are returned by the Go API as in-memory strings. However, this extra step accidentally didn't happen for all builds after the initial build when watch mode was enabled. This behavior used to work but it was broken in version 0.14.18 by the introduction of the mangle cache feature. This release fixes the combination of these features, so the metafile and mangle cache features should now work with watch mode. This behavior was only broken for the CLI, not for the JS or Go APIs.

• Add an original field to the metafile

  The metadata file JSON now has an additional field: each import in an input file now contains the pre-resolved path in the original field in addition to the post-resolved path in the path field. This means it's now possible to run certain additional analysis over your bundle. For example, you should be able to use this to detect when the same package subpath is represented multiple times in the bundle, either because multiple versions of a package were bundled or because a package is experiencing the dual-package hazard.

0.16.12

• Loader defaults to js for extensionless files (#2776)

  Certain packages contain files without an extension. For example, the yargs package contains the file yargs/yargs which has no extension. Node, Webpack, and Parcel can all understand code that imports yargs/yargs because they assume that the file is JavaScript. However, esbuild was previously unable to understand this code because it relies on the file extension to tell it how to interpret the file. With this release, esbuild will now assume files without an extension are JavaScript files. This can be customized by setting the loader for "" (the empty string, representing files without an extension) to another loader. For example, if you want files without an extension to be treated as CSS instead, you can do that like this:

  • CLI:

    esbuild --bundle --loader:=css
    

  • JS:

    esbuild.build({
      bundle: true,
      loader: { '': 'css' },
    })
    

  • Go:

    api.Build(api.BuildOptions{
    

... (truncated)

• 0db0b46 publish 0.16.13 to npm
• eda632d mention the bundle analyzer in the release notes
• 9234378 add the original field to the metafile
• d59ca10 feat: add markdown to guessed mime types (#2784)
• 59fd941 add a custom error message for #2783
• 6837c35 enable source maps for the json loader
• 16e77e7 fix test flake in watchMetafile
• 78a9be4 always use a plugin for post-build actions
• e4f32bb watch mode: print metafile analysis after rebuilds
• 867ef14 test coverage for: Cannot use "watch" with "serve"
• 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)