chore(deps): bump esbuild from 0.13.4 to 0.13.7 in /packages/stack/core

[dependabot]

Bumps esbuild from 0.13.4 to 0.13.7.

Release notes

Sourced from esbuild's releases.

v0.13.7

• Minify CSS alpha values correctly (#1682)

  When esbuild uses the rgba() syntax for a color instead of the 8-character hex code (e.g. when target is set to Chrome 61 or earlier), the 0-to-255 integer alpha value must be printed as a floating-point fraction between 0 and 1. The fraction was only printed to three decimal places since that is the minimal number of decimal places required for all 256 different alpha values to be uniquely determined. However, using three decimal places does not necessarily result in the shortest result. For example, 128 / 255 is 0.5019607843137255 which is printed as ".502" using three decimal places, but ".5" is equivalent because round(0.5 * 255) == 128, so printing ".5" would be better. With this release, esbuild will always use the minimal numeric representation for the alpha value:

  /* Original code */
  a { color: #FF800080 }
  /* Old output (with --minify --target=chrome61) */
  a{color:rgba(255,128,0,.502)}
  /* New output (with --minify --target=chrome61) */
  a{color:rgba(255,128,0,.5)}

• Match node's behavior for core module detection (#1680)

  Node has a hard-coded list of core modules (e.g. fs) that, when required, short-circuit the module resolution algorithm and instead return the corresponding internal core module object. When you pass --platform=node to esbuild, esbuild also implements this short-circuiting behavior and doesn't try to bundle these import paths. This was implemented in esbuild using the existing external feature (e.g. essentially --external:fs). However, there is an edge case where esbuild's external feature behaved differently than node.

  Modules specified via esbuild's external feature also cause all sub-paths to be excluded as well, so for example --external:foo excludes both foo and foo/bar from the bundle. However, node's core module check is only an exact equality check, so for example fs is a core module and bypasses the module resolution algorithm but fs/foo is not a core module and causes the module resolution algorithm to search the file system.

  This behavior can be used to load a module on the file system with the same name as one of node's core modules. For example, require('fs/') will load the module fs from the file system instead of loading node's core fs module. With this release, esbuild will now match node's behavior in this edge case. This means the external modules that are automatically added by --platform=node now behave subtly differently than --external:, which allows code that relies on this behavior to be bundled correctly.

• Fix WebAssembly builds on Go 1.17.2+ (#1684)

  Go 1.17.2 introduces a change (specifically a fix for CVE-2021-38297) that causes Go's WebAssembly bootstrap script to throw an error when it's run in situations with many environment variables. One such situation is when the bootstrap script is run inside GitHub Actions. This change was introduced because the bootstrap script writes a copy of the environment variables into WebAssembly memory without any bounds checking, and writing more than 4096 bytes of data ends up writing past the end of the buffer and overwriting who-knows-what. So throwing an error in this situation is an improvement. However, this breaks esbuild which previously (at least seemingly) worked fine.

  With this release, esbuild's WebAssembly bootstrap script that calls out to Go's WebAssembly bootstrap script will now delete all environment variables except for the ones that esbuild checks for, of which there are currently only four: NO_COLOR, NODE_PATH, npm_config_user_agent, and WT_SESSION. This should avoid a crash when esbuild is built using Go 1.17.2+ and should reduce the likelihood of memory corruption when esbuild is built using Go 1.17.1 or earlier. This release also updates the Go version that esbuild ships with to version 1.17.2. Note that this problem only affects the esbuild-wasm package. The esbuild package is not affected.

  See also:

  • golang/go#48797
  • golang/go#49011

v0.13.6

• Emit decorators for declare class fields (#1675)

  In version 3.7, TypeScript introduced the declare keyword for class fields that avoids generating any code for that field:

  // TypeScript input
  class Foo {
    a: number
    declare b: number
  }
  // JavaScript output
  class Foo {
  a;

... (truncated)

Changelog

Sourced from esbuild's changelog.

0.13.7

• Minify CSS alpha values correctly (#1682)

  When esbuild uses the rgba() syntax for a color instead of the 8-character hex code (e.g. when target is set to Chrome 61 or earlier), the 0-to-255 integer alpha value must be printed as a floating-point fraction between 0 and 1. The fraction was only printed to three decimal places since that is the minimal number of decimal places required for all 256 different alpha values to be uniquely determined. However, using three decimal places does not necessarily result in the shortest result. For example, 128 / 255 is 0.5019607843137255 which is printed as ".502" using three decimal places, but ".5" is equivalent because round(0.5 * 255) == 128, so printing ".5" would be better. With this release, esbuild will always use the minimal numeric representation for the alpha value:

  /* Original code */
  a { color: #FF800080 }
  /* Old output (with --minify --target=chrome61) */
  a{color:rgba(255,128,0,.502)}
  /* New output (with --minify --target=chrome61) */
  a{color:rgba(255,128,0,.5)}

• Match node's behavior for core module detection (#1680)

  Node has a hard-coded list of core modules (e.g. fs) that, when required, short-circuit the module resolution algorithm and instead return the corresponding internal core module object. When you pass --platform=node to esbuild, esbuild also implements this short-circuiting behavior and doesn't try to bundle these import paths. This was implemented in esbuild using the existing external feature (e.g. essentially --external:fs). However, there is an edge case where esbuild's external feature behaved differently than node.

  Modules specified via esbuild's external feature also cause all sub-paths to be excluded as well, so for example --external:foo excludes both foo and foo/bar from the bundle. However, node's core module check is only an exact equality check, so for example fs is a core module and bypasses the module resolution algorithm but fs/foo is not a core module and causes the module resolution algorithm to search the file system.

  This behavior can be used to load a module on the file system with the same name as one of node's core modules. For example, require('fs/') will load the module fs from the file system instead of loading node's core fs module. With this release, esbuild will now match node's behavior in this edge case. This means the external modules that are automatically added by --platform=node now behave subtly differently than --external:, which allows code that relies on this behavior to be bundled correctly.

• Fix WebAssembly builds on Go 1.17.2+ (#1684)

  Go 1.17.2 introduces a change (specifically a fix for CVE-2021-38297) that causes Go's WebAssembly bootstrap script to throw an error when it's run in situations with many environment variables. One such situation is when the bootstrap script is run inside GitHub Actions. This change was introduced because the bootstrap script writes a copy of the environment variables into WebAssembly memory without any bounds checking, and writing more than 4096 bytes of data ends up writing past the end of the buffer and overwriting who-knows-what. So throwing an error in this situation is an improvement. However, this breaks esbuild which previously (at least seemingly) worked fine.

  With this release, esbuild's WebAssembly bootstrap script that calls out to Go's WebAssembly bootstrap script will now delete all environment variables except for the ones that esbuild checks for, of which there are currently only four: NO_COLOR, NODE_PATH, npm_config_user_agent, and WT_SESSION. This should avoid a crash when esbuild is built using Go 1.17.2+ and should reduce the likelihood of memory corruption when esbuild is built using Go 1.17.1 or earlier. This release also updates the Go version that esbuild ships with to version 1.17.2. Note that this problem only affects the esbuild-wasm package. The esbuild package is not affected.

  See also:

  • golang/go#48797
  • golang/go#49011

0.13.6

• Emit decorators for declare class fields (#1675)

  In version 3.7, TypeScript introduced the declare keyword for class fields that avoids generating any code for that field:

  // TypeScript input
  class Foo {
    a: number
    declare b: number
  }
  // JavaScript output

... (truncated)

Commits

• 68e369d publish 0.13.7 to npm
• 8b77de1 update rollup tests so they work on node v16.11.1
• ae754ae fix wasm on go 1.17.2 (#1684)
• 344ec46 update go 1.17.1 => 1.17.2
• b2d7329 fix #1680: match node's core module behavior
• 85f85f2 fix #1682: always use the shortest css alpha value
• 8b5d6e9 update benchmark image
• 91bfb9f update rollup and webpack too
• fb0856f remove old bundler versions
• 929b172 remove now-unnecessary "@​parcel/transformer-typescript-tsc"
• 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)