Bump esbuild from 0.8.57 to 0.14.17

[dependabot[bot]]

Bumps esbuild from 0.8.57 to 0.14.17.

Release notes

Sourced from esbuild's releases.

v0.14.17

• Attempt to fix an install script issue on Ubuntu Linux (#1711)

  There have been some reports of esbuild failing to install on Ubuntu Linux for a while now. I haven't been able to reproduce this myself due to lack of reproduction instructions until today, when I learned that the issue only happens when you install node from the Snap Store instead of downloading the official version of node.

  The problem appears to be that when node is installed from the Snap Store, install scripts are run with stderr not being writable? This then appears to cause a problem for esbuild's install script when it uses execFileSync to validate that the esbuild binary is working correctly. This throws the error EACCES: permission denied, write even though this particular command never writes to stderr.

  Node's documentation says that stderr for execFileSync defaults to that of the parent process. Forcing it to 'pipe' instead appears to fix the issue, although I still don't fully understand what's happening or why. I'm publishing this small change regardless to see if it fixes this install script edge case.

• Avoid a syntax error due to --mangle-props=. and super() (#1976)

  This release fixes an issue where passing --mangle-props=. (i.e. telling esbuild to mangle every single property) caused a syntax error with code like this:

  class Foo {}
  class Bar extends Foo {
    constructor() {
      super();
    }
  }
  

  The problem was that constructor was being renamed to another method, which then made it no longer a constructor, which meant that super() was now a syntax error. I have added a workaround that avoids renaming any property named constructor so that esbuild doesn't generate a syntax error here.

  Despite this fix, I highly recommend not using --mangle-props=. because your code will almost certainly be broken. You will have to manually add every single property that you don't want mangled to --reserve-props= which is an excessive maintenance burden (e.g. reserve parse to use JSON.parse). Instead I recommend using a common pattern for all properties you intend to be mangled that is unlikely to appear in the APIs you use such as "ends in an underscore." This is an opt-in approach instead of an opt-out approach. It also makes it obvious when reading the code which properties will be mangled and which ones won't be.

v0.14.16

• Support property name mangling with some TypeScript syntax features

  The newly-released --mangle-props= feature previously only affected JavaScript syntax features. This release adds support for using mangle props with certain TypeScript syntax features:

  • TypeScript parameter properties

    Parameter properties are a TypeScript-only shorthand way of initializing a class field directly from the constructor argument list. Previously parameter properties were not treated as properties to be mangled. They should now be handled correctly:

    // Original code
    class Foo {
      constructor(public foo_) {}
    }
    new Foo().foo_;
    // Old output (with --minify --mangle-props=)
    class Foo{constructor(c){this.foo=c}}new Foo().o;
    // New output (with --minify --mangle-props=_)
    class Foo{constructor(o){this.c=o}}new Foo().c;
    

  • TypeScript namespaces

... (truncated)

Changelog

Sourced from esbuild's changelog.

0.14.17

• Attempt to fix an install script issue on Ubuntu Linux (#1711)

  There have been some reports of esbuild failing to install on Ubuntu Linux for a while now. I haven't been able to reproduce this myself due to lack of reproduction instructions until today, when I learned that the issue only happens when you install node from the Snap Store instead of downloading the official version of node.

  The problem appears to be that when node is installed from the Snap Store, install scripts are run with stderr not being writable? This then appears to cause a problem for esbuild's install script when it uses execFileSync to validate that the esbuild binary is working correctly. This throws the error EACCES: permission denied, write even though this particular command never writes to stderr.

  Node's documentation says that stderr for execFileSync defaults to that of the parent process. Forcing it to 'pipe' instead appears to fix the issue, although I still don't fully understand what's happening or why. I'm publishing this small change regardless to see if it fixes this install script edge case.

• Avoid a syntax error due to --mangle-props=. and super() (#1976)

  This release fixes an issue where passing --mangle-props=. (i.e. telling esbuild to mangle every single property) caused a syntax error with code like this:

  class Foo {}
  class Bar extends Foo {
    constructor() {
      super();
    }
  }
  

  The problem was that constructor was being renamed to another method, which then made it no longer a constructor, which meant that super() was now a syntax error. I have added a workaround that avoids renaming any property named constructor so that esbuild doesn't generate a syntax error here.

  Despite this fix, I highly recommend not using --mangle-props=. because your code will almost certainly be broken. You will have to manually add every single property that you don't want mangled to --reserve-props= which is an excessive maintenance burden (e.g. reserve parse to use JSON.parse). Instead I recommend using a common pattern for all properties you intend to be mangled that is unlikely to appear in the APIs you use such as "ends in an underscore." This is an opt-in approach instead of an opt-out approach. It also makes it obvious when reading the code which properties will be mangled and which ones won't be.

0.14.16

• Support property name mangling with some TypeScript syntax features

  The newly-released --mangle-props= feature previously only affected JavaScript syntax features. This release adds support for using mangle props with certain TypeScript syntax features:

  • TypeScript parameter properties

    Parameter properties are a TypeScript-only shorthand way of initializing a class field directly from the constructor argument list. Previously parameter properties were not treated as properties to be mangled. They should now be handled correctly:

    // Original code
    class Foo {
      constructor(public foo_) {}
    }
    new Foo().foo_;
    // Old output (with --minify --mangle-props=)
    class Foo{constructor(c){this.foo=c}}new Foo().o;
    // New output (with --minify --mangle-props=_)
    class Foo{constructor(o){this.c=o}}new Foo().c;
    

... (truncated)

Commits

• 43a7ce6 publish 0.14.17 to npm
• 54ebf0c fix #1711: attempt to fix install script with snap
• b86e208 gracefully handle props mangled to non-identifiers
• 7fc04c1 add "--mangle-props" to cli hints list
• 3dd6c57 fix #1976: parse "super()" with "--mangle-props=."
• 4cc9406 s/TypeScript/JavaScript/
• 8da1c79 publish 0.14.16 to npm
• 8b7fab9 s/fix/support/
• 2f922be fix compiler panic with lowered class fields
• fb510ff mangle props uses object shorthand if possible
• 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 #119.