chore(deps): update dependency esbuild to v0.14.34 #105
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This PR contains the following updates:
0.14.31
->0.14.34
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 tosuper()
, which is invalid. This problem has now been fixed (notice thatthis
is now used aftersuper()
instead of before):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 newsuper()
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) adjustingsuper()
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:
We can't just lower static fields without also lowering private members, since that causes a syntax error:
And the reason lowering private members requires adjusting
super()
calls is because the injected private member initializers usethis
, which is only accessible aftersuper()
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:
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):The injection of the automatically-generated
_Foo
variable is necessary to preserve the semantics of the capturedFoo
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 ifFoo
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: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 than4294967295
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 thesuper
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: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 allsuper
property accesses on instances including those inside loweredasync
functions. The new approach is different but should be equivalent to the old approach: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:
Add the
wasmModule
option to theinitialize
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 thewasmURL
API option like this:With this release, you can now also initialize esbuild using a
WebAssembly.Module
instance using thewasmModule
API option instead. The example above is equivalent to the following code: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.
This PR has been generated by WhiteSource Renovate. View repository job log here.