Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

chore(deps): update dependency esbuild to v0.14.34 #105

Merged
merged 1 commit into from
Apr 8, 2022

Conversation

renovate[bot]
Copy link
Contributor

@renovate renovate bot commented Apr 7, 2022

WhiteSource Renovate

This PR contains the following updates:

Package Change Age Adoption Passing Confidence
esbuild 0.14.31 -> 0.14.34 age adoption passing confidence

Release Notes

evanw/esbuild

v0.14.34

Compare Source

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

v0.14.33

Compare Source

  • 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 code
    class Foo extends Object {
      static FOO;
      constructor() {
        super();
      }
      #foo;
    }
    
    // Old output (with --bundle)
    var _foo;
    var Foo = class extends Object {
      constructor() {
        __privateAdd(this, _foo, void 0);
        super();
      }
    };
    _foo = new WeakMap();
    __publicField(Foo, "FOO");
    
    // New output (with --bundle)
    var _foo;
    var Foo = class extends Object {
      constructor() {
        super();
        __privateAdd(this, _foo, void 0);
      }
    };
    _foo = new WeakMap();
    __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:

    class Foo {
      get #foo() {}
      static bar = new Foo().#foo
    }

    We can't just lower static fields without also lowering private members, since that causes a syntax error:

    class Foo {
      get #foo() {}
    }
    Foo.bar = new Foo().#foo;

    And the reason lowering private members requires adjusting super() calls is because the injected private member initializers use this, which is only accessible after super() calls in the constructor.

  • Fix an issue with --keep-names not keeping some names (#​2149)

    This release fixes a regression with --keep-names from version 0.14.26. PR #​2062 attempted to remove superfluous calls to the __name helper function by omitting calls of the form __name(foo, "foo") where the name of the symbol in the first argument is equal to the string in the second argument. This was assuming that the initializer for the symbol would automatically be assigned the expected .name property by the JavaScript VM, which turned out to be an incorrect assumption. To fix the regression, this PR has been reverted.

    The assumption is true in many cases but isn't true when the initializer is moved into another automatically-generated variable, which can sometimes be necessary during the various syntax transformations that esbuild does. For example, consider the following code:

    class Foo {
      static get #foo() { return Foo.name }
      static get foo() { return this.#foo }
    }
    let Bar = Foo
    Foo = { name: 'Bar' }
    console.log(Foo.name, Bar.name)

    This code should print Bar Foo. With --keep-names --target=es6 that code is lowered by esbuild into the following code (omitting the helper function definitions for brevity):

    var _foo, foo_get;
    const _Foo = class {
      static get foo() {
        return __privateGet(this, _foo, foo_get);
      }
    };
    let Foo = _Foo;
    __name(Foo, "Foo");
    _foo = new WeakSet();
    foo_get = /* @​__PURE__ */ __name(function() {
      return _Foo.name;
    }, "#foo");
    __privateAdd(Foo, _foo);
    let Bar = Foo;
    Foo = { name: "Bar" };
    console.log(Foo.name, Bar.name);

    The injection of the automatically-generated _Foo variable is necessary to preserve the semantics of the captured Foo binding for methods defined within the class body, even when the definition needs to be moved outside of the class body during code transformation. Due to a JavaScript quirk, this binding is immutable and does not change even if Foo is later reassigned. The PR that was reverted was incorrectly removing the call to __name(Foo, "Foo"), which turned out to be necessary after all in this case.

  • Print some large integers using hexadecimal when minifying (#​2162)

    When --minify is active, esbuild will now use one fewer byte to represent certain large integers:

    // Original code
    x = 123456787654321;
    
    // Old output (with --minify)
    x=123456787654321;
    
    // New output (with --minify)
    x=0x704885f926b1;

    This works because a hexadecimal representation can be shorter than a decimal representation starting at around 1012 and above.

    This optimization made me realize that there's probably an opportunity to optimize printed numbers for smaller gzipped size instead of or in addition to just optimizing for minimal uncompressed byte count. The gzip algorithm does better with repetitive sequences, so for example 0xFFFFFFFF is probably a better representation than 4294967295 even though the byte counts are the same. As far as I know, no JavaScript minifier does this optimization yet. I don't know enough about how gzip works to know if this is a good idea or what the right metric for this might be.

  • Add Linux ARM64 support for Deno (#​2156)

    This release adds Linux ARM64 support to esbuild's Deno API implementation, which allows esbuild to be used with Deno on a Raspberry Pi.

v0.14.32

Compare Source

  • Fix super usage in lowered private methods (#​2039)

    Previously esbuild failed to transform super property accesses inside private methods in the case when private methods have to be lowered because the target environment doesn't support them. The generated code still contained the super keyword even though the method was moved outside of the class body, which is a syntax error in JavaScript. This release fixes this transformation issue and now produces valid code:

    // Original code
    class Derived extends Base {
      #foo() { super.foo() }
      bar() { this.#foo() }
    }
    
    // Old output (with --target=es6)
    var _foo, foo_fn;
    class Derived extends Base {
      constructor() {
        super(...arguments);
        __privateAdd(this, _foo);
      }
      bar() {
        __privateMethod(this, _foo, foo_fn).call(this);
      }
    }
    _foo = new WeakSet();
    foo_fn = function() {
      super.foo();
    };
    
    // New output (with --target=es6)
    var _foo, foo_fn;
    const _Derived = class extends Base {
      constructor() {
        super(...arguments);
        __privateAdd(this, _foo);
      }
      bar() {
        __privateMethod(this, _foo, foo_fn).call(this);
      }
    };
    let Derived = _Derived;
    _foo = new WeakSet();
    foo_fn = function() {
      __superGet(_Derived.prototype, this, "foo").call(this);
    };

    Because of this change, lowered super property accesses on instances were rewritten so that they can exist outside of the class body. This rewrite affects code generation for all super property accesses on instances including those inside lowered async functions. The new approach is different but should be equivalent to the old approach:

    // Original code
    class Foo {
      foo = async () => super.foo()
    }
    
    // Old output (with --target=es6)
    class Foo {
      constructor() {
        __publicField(this, "foo", () => {
          var __superGet = (key) => super[key];
          return __async(this, null, function* () {
            return __superGet("foo").call(this);
          });
        });
      }
    }
    
    // New output (with --target=es6)
    class Foo {
      constructor() {
        __publicField(this, "foo", () => __async(this, null, function* () {
          return __superGet(Foo.prototype, this, "foo").call(this);
        }));
      }
    }
  • Fix some tree-shaking bugs regarding property side effects

    This release fixes some cases where side effects in computed properties were not being handled correctly. Specifically primitives and private names as properties should not be considered to have side effects, and object literals as properties should be considered to have side effects:

    // Original code
    let shouldRemove = { [1]: 2 }
    let shouldRemove2 = class { #foo }
    let shouldKeep = class { [{ toString() { sideEffect() } }] }
    
    // Old output (with --tree-shaking=true)
    let shouldRemove = { [1]: 2 };
    let shouldRemove2 = class {
      #foo;
    };
    
    // New output (with --tree-shaking=true)
    let shouldKeep = class {
      [{ toString() {
        sideEffect();
      } }];
    };
  • Add the wasmModule option to the initialize JS API (#​1093)

    The initialize JS API must be called when using esbuild in the browser to provide the WebAssembly module for esbuild to use. Previously the only way to do that was using the wasmURL API option like this:

    await esbuild.initialize({
      wasmURL: '/node_modules/esbuild-wasm/esbuild.wasm',
    })
    console.log(await esbuild.transform('1+2'))

    With this release, you can now also initialize esbuild using a WebAssembly.Module instance using the wasmModule API option instead. The example above is equivalent to the following code:

    await esbuild.initialize({
      wasmModule: await WebAssembly.compileStreaming(fetch('/node_modules/esbuild-wasm/esbuild.wasm'))
    })
    console.log(await esbuild.transform('1+2'))

    This could be useful for environments where you want more control over how the WebAssembly download happens or where downloading the WebAssembly module is not possible.


Configuration

📅 Schedule: At any time (no schedule defined).

🚦 Automerge: Enabled.

Rebasing: Whenever PR is behind base branch, or you tick the rebase/retry checkbox.

🔕 Ignore: Close this PR and you won't be reminded about this update again.


  • If you want to rebase/retry this PR, click this checkbox.

This PR has been generated by WhiteSource Renovate. View repository job log here.

@renovate renovate bot added the renovate label Apr 7, 2022
@renovate
Copy link
Contributor Author

renovate bot commented Apr 7, 2022

Branch automerge failure

This PR was configured for branch automerge, however this is not possible so it has been raised as a PR instead.


  • Branch has one or more failed status checks

Signed-off-by: Renovate Bot <bot@renovateapp.com>
@renovate renovate bot merged commit 755d731 into master Apr 8, 2022
@renovate renovate bot deleted the renovate/esbuild-0.x branch April 8, 2022 06:40
@github-actions
Copy link

github-actions bot commented May 2, 2022

🎉 This PR is included in version 1.11.0 🎉

The release is available on:

Your semantic-release bot 📦🚀

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant