Bump esbuild from 0.14.31 to 0.14.34

[dependabot]

Bumps esbuild from 0.14.31 to 0.14.34.

Release notes

Sourced from esbuild's releases.

v0.14.34

Something went wrong with the publishing script for the previous release. Publishing again.

v0.14.33

• Fix a regression regarding super (#2158)

  This fixes a regression from the previous release regarding classes with a super class, a private member, and a static field in the scenario where the static field needs to be lowered but where private members are supported by the configured target environment. In this scenario, esbuild could incorrectly inject the instance field initializers that use this into the constructor before the call to super(), which is invalid. This problem has now been fixed (notice that this is now used after super() instead of before):

  // Original codeclassFooextendsObject{staticFOO;constructor(){super();}
  #foo;}// Old output (with --bundle)var_foo;varFoo=classextendsObject{constructor(){__privateAdd(this,_foo,void0);super();}};_foo=newWeakMap();__publicField(Foo,"FOO");// New output (with --bundle)var_foo;varFoo=classextendsObject{constructor(){super();__privateAdd(this,_foo,void0);}};_foo=newWeakMap();__publicField(Foo,"FOO");

  During parsing, esbuild scans the class and makes certain decisions about the class such as whether to lower all static fields, whether to lower each private member, or whether calls to super() need to be tracked and adjusted. Previously esbuild made two passes through the class members to compute this information. However, with the new super() call lowering logic added in the previous release, we now need three passes to capture the whole dependency chain for this case: 1) lowering static fields requires 2) lowering private members which requires 3) adjusting super() calls.

  The reason lowering static fields requires lowering private members is because lowering static fields moves their initializers outside of the class body, where they can't access private members anymore. Consider this code:

  classFoo{get #foo(){}staticbar=newFoo().#foo
  }

... (truncated)

Changelog

Sourced from esbuild's changelog.

0.14.34

Something went wrong with the publishing script for the previous release. Publishing again.

0.14.33

• Fix a regression regarding super (#2158)

  This fixes a regression from the previous release regarding classes with a super class, a private member, and a static field in the scenario where the static field needs to be lowered but where private members are supported by the configured target environment. In this scenario, esbuild could incorrectly inject the instance field initializers that use this into the constructor before the call to super(), which is invalid. This problem has now been fixed (notice that this is now used after super() instead of before):

  // Original codeclassFooextendsObject{staticFOO;constructor(){super();}
  #foo;}// Old output (with --bundle)var_foo;varFoo=classextendsObject{constructor(){__privateAdd(this,_foo,void0);super();}};_foo=newWeakMap();__publicField(Foo,"FOO");// New output (with --bundle)var_foo;varFoo=classextendsObject{constructor(){super();__privateAdd(this,_foo,void0);}};_foo=newWeakMap();__publicField(Foo,"FOO");

  During parsing, esbuild scans the class and makes certain decisions about the class such as whether to lower all static fields, whether to lower each private member, or whether calls to super() need to be tracked and adjusted. Previously esbuild made two passes through the class members to compute this information. However, with the new super() call lowering logic added in the previous release, we now need three passes to capture the whole dependency chain for this case: 1) lowering static fields requires 2) lowering private members which requires 3) adjusting super() calls.

  The reason lowering static fields requires lowering private members is because lowering static fields moves their initializers outside of the class body, where they can't access private members anymore. Consider this code:

  classFoo{get #foo(){}

... (truncated)

Commits

• 6246020 publish 0.14.34 to npm
• 4872426 publish 0.14.33 to npm
• cbe422f fix #2149: changelog entry about reverting #2062
• 046f82f Revert "Drop superfluous __name() calls (#2062)"
• 57a75a8 fix #2162: some numbers now print slightly smaller
• bdee212 fix #2158: private+super+static+bundle edge case
• 9ce27c8 fix #2156: linux arm64 support for deno
• 5829301 publish 0.14.32 to npm
• 44d70d3 add wasmModule option to initialize JS API (#2155)
• e86abce mark symbol static properties as side-effect free
• 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]

Superseded by #60.