Bump esbuild from 0.14.54 to 0.15.8

[dependabot[bot]]

Bumps esbuild from 0.14.54 to 0.15.8.

Release notes

Sourced from esbuild's releases.

v0.15.8

• Fix JSX name collision edge case (#2534)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

... (truncated)

Changelog

Sourced from esbuild's changelog.

0.15.8

• Fix JSX name collision edge case (#2534)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

... (truncated)

Commits

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

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

---

Dependabot commands and options

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)

[dependabot[bot]]

Superseded by #90.