This repository has been archived by the owner on Jul 31, 2022. It is now read-only.
-
Notifications
You must be signed in to change notification settings - Fork 71
chore(deps): update dependency esbuild to v0.14.36 #368
Open
renovate
wants to merge
1
commit into
master
Choose a base branch
from
renovate/esbuild-0.x
base: master
Could not load branches
Branch not found: {{ refName }}
Loading
Could not load tags
Nothing to show
Loading
Are you sure you want to change the base?
Some commits from the old base branch may be removed from the timeline,
and old review comments may become outdated.
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
renovate
bot
force-pushed
the
renovate/esbuild-0.x
branch
from
December 4, 2021 08:23
255fa6e
to
38cf907
Compare
renovate
bot
changed the title
chore(deps): update dependency esbuild to v0.14.1
chore(deps): update dependency esbuild to v0.14.2
Dec 4, 2021
renovate
bot
force-pushed
the
renovate/esbuild-0.x
branch
2 times, most recently
from
December 10, 2021 02:17
5cf0a50
to
df82fbc
Compare
|
renovate
bot
force-pushed
the
renovate/esbuild-0.x
branch
from
December 12, 2021 19:07
df82fbc
to
2c5732c
Compare
renovate
bot
changed the title
chore(deps): update dependency esbuild to v0.14.2
chore(deps): update dependency esbuild to v0.14.3
Dec 12, 2021
renovate
bot
force-pushed
the
renovate/esbuild-0.x
branch
from
December 14, 2021 17:41
2c5732c
to
108395b
Compare
renovate
bot
changed the title
chore(deps): update dependency esbuild to v0.14.3
chore(deps): update dependency esbuild to v0.14.4
Dec 14, 2021
renovate
bot
force-pushed
the
renovate/esbuild-0.x
branch
from
December 14, 2021 20:03
108395b
to
9be3553
Compare
renovate
bot
changed the title
chore(deps): update dependency esbuild to v0.14.4
chore(deps): update dependency esbuild to v0.14.5
Dec 14, 2021
renovate
bot
force-pushed
the
renovate/esbuild-0.x
branch
from
December 20, 2021 08:08
9be3553
to
95e9d44
Compare
renovate
bot
changed the title
chore(deps): update dependency esbuild to v0.14.5
chore(deps): update dependency esbuild to v0.14.6
Dec 20, 2021
renovate
bot
force-pushed
the
renovate/esbuild-0.x
branch
from
December 21, 2021 20:07
95e9d44
to
1ecd60d
Compare
renovate
bot
changed the title
chore(deps): update dependency esbuild to v0.14.6
chore(deps): update dependency esbuild to v0.14.7
Dec 21, 2021
renovate
bot
force-pushed
the
renovate/esbuild-0.x
branch
from
December 23, 2021 08:57
1ecd60d
to
4ebec89
Compare
renovate
bot
changed the title
chore(deps): update dependency esbuild to v0.14.7
chore(deps): update dependency esbuild to v0.14.8
Dec 23, 2021
renovate
bot
force-pushed
the
renovate/esbuild-0.x
branch
from
December 29, 2021 01:18
4ebec89
to
681ae29
Compare
renovate
bot
changed the title
chore(deps): update dependency esbuild to v0.14.8
chore(deps): update dependency esbuild to v0.14.9
Dec 29, 2021
renovate
bot
force-pushed
the
renovate/esbuild-0.x
branch
from
December 31, 2021 17:11
681ae29
to
e4f09ec
Compare
renovate
bot
changed the title
chore(deps): update dependency esbuild to v0.14.9
chore(deps): update dependency esbuild to v0.14.10
Dec 31, 2021
renovate
bot
force-pushed
the
renovate/esbuild-0.x
branch
from
January 9, 2022 00:48
e4f09ec
to
8558c2f
Compare
renovate
bot
changed the title
chore(deps): update dependency esbuild to v0.14.10
chore(deps): update dependency esbuild to v0.14.11
Jan 9, 2022
renovate
bot
force-pushed
the
renovate/esbuild-0.x
branch
from
January 21, 2022 02:06
8558c2f
to
d1b1524
Compare
renovate
bot
changed the title
chore(deps): update dependency esbuild to v0.14.11
chore(deps): update dependency esbuild to v0.14.12
Jan 21, 2022
renovate
bot
force-pushed
the
renovate/esbuild-0.x
branch
from
January 22, 2022 16:25
d1b1524
to
1b3962f
Compare
renovate
bot
changed the title
chore(deps): update dependency esbuild to v0.14.12
chore(deps): update dependency esbuild to v0.14.13
Jan 22, 2022
renovate
bot
force-pushed
the
renovate/esbuild-0.x
branch
from
January 26, 2022 00:57
1b3962f
to
f4211a5
Compare
renovate
bot
changed the title
chore(deps): update dependency esbuild to v0.14.13
chore(deps): update dependency esbuild to v0.14.14
Jan 26, 2022
renovate
bot
force-pushed
the
renovate/esbuild-0.x
branch
from
February 9, 2022 12:02
addaa42
to
9b9b6fa
Compare
renovate
bot
force-pushed
the
renovate/esbuild-0.x
branch
from
February 17, 2022 00:05
9b9b6fa
to
66225bb
Compare
renovate
bot
changed the title
chore(deps): update dependency esbuild to v0.14.21
chore(deps): update dependency esbuild to v0.14.22
Feb 17, 2022
renovate
bot
force-pushed
the
renovate/esbuild-0.x
branch
from
February 18, 2022 20:23
66225bb
to
108bc2b
Compare
renovate
bot
changed the title
chore(deps): update dependency esbuild to v0.14.22
chore(deps): update dependency esbuild to v0.14.23
Feb 18, 2022
renovate
bot
force-pushed
the
renovate/esbuild-0.x
branch
from
March 3, 2022 08:53
108bc2b
to
4d38b09
Compare
renovate
bot
changed the title
chore(deps): update dependency esbuild to v0.14.23
chore(deps): update dependency esbuild to v0.14.24
Mar 3, 2022
renovate
bot
force-pushed
the
renovate/esbuild-0.x
branch
from
March 4, 2022 09:07
4d38b09
to
0cc2d88
Compare
renovate
bot
changed the title
chore(deps): update dependency esbuild to v0.14.24
chore(deps): update dependency esbuild to v0.14.25
Mar 4, 2022
renovate
bot
force-pushed
the
renovate/esbuild-0.x
branch
from
March 14, 2022 08:39
0cc2d88
to
829a320
Compare
renovate
bot
changed the title
chore(deps): update dependency esbuild to v0.14.25
chore(deps): update dependency esbuild to v0.14.26
Mar 14, 2022
renovate
bot
force-pushed
the
renovate/esbuild-0.x
branch
from
March 14, 2022 23:42
829a320
to
a6f6afa
Compare
renovate
bot
changed the title
chore(deps): update dependency esbuild to v0.14.26
chore(deps): update dependency esbuild to v0.14.27
Mar 14, 2022
renovate
bot
force-pushed
the
renovate/esbuild-0.x
branch
from
March 26, 2022 04:50
a6f6afa
to
5df52af
Compare
renovate
bot
changed the title
chore(deps): update dependency esbuild to v0.14.27
chore(deps): update dependency esbuild to v0.14.28
Mar 26, 2022
renovate
bot
force-pushed
the
renovate/esbuild-0.x
branch
from
March 30, 2022 04:10
5df52af
to
a6fe29b
Compare
renovate
bot
changed the title
chore(deps): update dependency esbuild to v0.14.28
chore(deps): update dependency esbuild to v0.14.29
Mar 30, 2022
renovate
bot
force-pushed
the
renovate/esbuild-0.x
branch
from
April 2, 2022 12:34
a6fe29b
to
dfd5587
Compare
renovate
bot
changed the title
chore(deps): update dependency esbuild to v0.14.29
chore(deps): update dependency esbuild to v0.14.30
Apr 2, 2022
renovate
bot
force-pushed
the
renovate/esbuild-0.x
branch
from
April 4, 2022 07:04
dfd5587
to
d069f81
Compare
renovate
bot
changed the title
chore(deps): update dependency esbuild to v0.14.30
chore(deps): update dependency esbuild to v0.14.31
Apr 4, 2022
renovate
bot
force-pushed
the
renovate/esbuild-0.x
branch
from
April 6, 2022 05:22
d069f81
to
24bed5c
Compare
renovate
bot
changed the title
chore(deps): update dependency esbuild to v0.14.31
chore(deps): update dependency esbuild to v0.14.32
Apr 6, 2022
renovate
bot
force-pushed
the
renovate/esbuild-0.x
branch
from
April 7, 2022 10:14
24bed5c
to
0991030
Compare
renovate
bot
changed the title
chore(deps): update dependency esbuild to v0.14.32
chore(deps): update dependency esbuild to v0.14.34
Apr 7, 2022
renovate
bot
force-pushed
the
renovate/esbuild-0.x
branch
from
April 12, 2022 03:03
0991030
to
b1865ed
Compare
renovate
bot
changed the title
chore(deps): update dependency esbuild to v0.14.34
chore(deps): update dependency esbuild to v0.14.35
Apr 12, 2022
renovate
bot
force-pushed
the
renovate/esbuild-0.x
branch
from
April 12, 2022 11:03
b1865ed
to
883f9e2
Compare
renovate
bot
changed the title
chore(deps): update dependency esbuild to v0.14.35
chore(deps): update dependency esbuild to v0.14.36
Apr 12, 2022
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
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.13.15
->0.14.36
Release Notes
evanw/esbuild
v0.14.36
Compare Source
Revert path metadata validation for now (#2177)
This release reverts the path metadata validation that was introduced in the previous release. This validation has uncovered a potential issue with how esbuild handles
onResolve
callbacks in plugins that will need to be fixed before path metadata validation is re-enabled.v0.14.35
Compare Source
Add support for parsing
typeof
on #private fields from TypeScript 4.7 (#2174)The upcoming version of TypeScript now lets you use
#private
fields intypeof
type expressions:https://devblogs.microsoft.com/typescript/announcing-typescript-4-7-beta/#typeof-on-private-fields
With this release, esbuild can now parse these new type expressions as well. This feature was contributed by @magic-akari.
Add Opera and IE to internal CSS feature support matrix (#2170)
Version 0.14.18 of esbuild added Opera and IE as available target environments, and added them to the internal JS feature support matrix. CSS feature support was overlooked, however. This release adds knowledge of Opera and IE to esbuild's internal CSS feature support matrix:
The fix for this issue was contributed by @sapphi-red.
Change TypeScript class field behavior when targeting ES2022
TypeScript 4.3 introduced a breaking change where class field behavior changes from assign semantics to define semantics when the
target
setting intsconfig.json
is set toESNext
. Specifically, the default value for TypeScript'suseDefineForClassFields
setting when unspecified istrue
if and only iftarget
isESNext
. TypeScript 4.6 introduced another change where this behavior now happens for bothESNext
andES2022
. Presumably this will be the case forES2023
and up as well. With this release, esbuild's behavior has also been changed to match. Now configuring esbuild with--target=es2022
will also cause TypeScript files to use the new class field behavior.Validate that path metadata returned by plugins is consistent
The plugin API assumes that all metadata for the same path returned by a plugin's
onResolve
callback is consistent. Previously this assumption was just assumed without any enforcement. Starting with this release, esbuild will now enforce this by generating a build error if this assumption is violated. The lack of validation has not been an issue (I have never heard of this being a problem), but it still seems like a good idea to enforce it. Here's a simple example of a plugin that generates inconsistentsideEffects
metadata:Since esbuild processes everything in parallel, the set of metadata that ends up being used for a given path is essentially random since it's whatever the task scheduler decides to schedule first. Thus if a plugin does not consistently provide the same metadata for a given path, subsequent builds may return different results. This new validation check prevents this problem.
Here's the new error message that's shown when this happens:
Suggest enabling a missing condition when
exports
map fails (#2163)This release adds another suggestion to the error message that happens when an
exports
map lookup fails if the failure could potentially be fixed by adding a missing condition. Here's what the new error message looks like (which now suggests--conditions=module
as a possible workaround):This particular package had an issue where it was using the Webpack-specific
module
condition without providing adefault
condition. It looks like the intent in this case was to use the standardimport
condition instead. This specific change wasn't suggested here because this error message is for package consumers, not package authors.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.
v0.14.31
Compare Source
Add support for parsing "optional variance annotations" from TypeScript 4.7 (#2102)
The upcoming version of TypeScript now lets you specify
in
and/orout
on certain type parameters (specifically only on a type alias, an interface declaration, or a class declaration). These modifiers control type paramemter covariance and contravariance:With this release, esbuild can now parse these new type parameter modifiers. This feature was contributed by @magic-akari.
Improve support for
super()
constructor calls in nested locations (#2134)In JavaScript, derived classes must call
super()
somewhere in theconstructor
method before being able to accessthis
. Class public instance fields, class private instance fields, and TypeScript constructor parameter properties can all potentially cause code which usesthis
to be inserted into the constructor body, which must be inserted after thesuper()
call. To make these insertions straightforward to implement, the TypeScript compiler doesn't allow callingsuper()
somewhere other than in a root-level statement in the constructor body in these cases.Previously esbuild's class transformations only worked correctly when
super()
was called in a root-level statement in the constructor body, just like the TypeScript compiler. But with this release, esbuild should now generate correct code as long as the call tosuper()
appears anywhere in the constructor body:Add support for the new
@container
CSS rule (#2127)This release adds support for
@container
in CSS files. This means esbuild will now pretty-print and minify these rules better since it now better understands the internal structure of these rules:This was contributed by @yisibl.
Avoid CSS cascade-dependent keywords in the
font-family
property (#2135)In CSS,
initial
,inherit
, andunset
are CSS-wide keywords which means they have special behavior when they are specified as a property value. For example, whilefont-family: 'Arial'
(as a string) andfont-family: Arial
(as an identifier) are the same,font-family: 'inherit'
(as a string) uses the font family namedinherit
butfont-family: inherit
(as an identifier) inherits the font family from the parent element. This means esbuild must not unquote these CSS-wide keywords (anddefault
, which is also reserved) during minification to avoid changing the meaning of the minified CSS.The current draft of the new CSS Cascading and Inheritance Level 5 specification adds another concept called cascade-dependent keywords of which there are two:
revert
andrevert-layer
. This release of esbuild guards against unquoting these additional keywords as well to avoid accidentally breaking pages that use a font with the same name:This fix was contributed by @yisibl.
v0.14.30
Compare Source
Change the context of TypeScript parameter decorators (#2147)
While TypeScript parameter decorators are expressions, they are not evaluated where they exist in the code. They are moved to after the class declaration and evaluated there instead. Specifically this TypeScript code:
becomes this JavaScript code:
This has several consequences:
Whether
await
is allowed inside a decorator expression or not depends on whether the class declaration itself is in anasync
context or not. With this release, you can now useawait
inside a decorator expression when the class declaration is either inside anasync
function or is at the top-level of an ES module and top-level await is supported. Note that the TypeScript compiler currently has a bug regarding this edge case: Parameter decorators use incorrect async/await context, generated code has syntax error microsoft/TypeScript#48509.Also while TypeScript currently allows
await
to be used like this inasync
functions, it doesn't currently allowyield
to be used like this in generator functions. It's not yet clear whether this behavior withyield
is a bug or by design, so I haven't made any changes to esbuild's handling ofyield
inside decorator expressions in this release.Since the scope of a decorator expression is the scope enclosing the class declaration, they cannot access private identifiers. Previously this was incorrectly allowed but with this release, esbuild no longer allows this. Note that the TypeScript compiler currently has a bug regarding this edge case: Decorators broken with private fields, generated code has syntax error microsoft/TypeScript#48515.
Since the scope of a decorator expression is the scope enclosing the class declaration, identifiers inside parameter decorator expressions should never be resolved to a parameter of the enclosing method. Previously this could happen, which was a bug with esbuild. This bug no longer happens in this release.
Specifically previous versions of esbuild generated the following incorrect JavaScript (notice the use of
arg2
):This release now generates the following correct JavaScript (notice the use of
arg
):Fix some obscure edge cases with
super
property accessThis release fixes the following obscure problems with
super
when targeting an older JavaScript environment such as--target=es6
:The compiler could previously crash when a lowered
async
arrow function contained a class with a field initializer that used asuper
property access:The compiler could previously generate incorrect code when a lowered
async
method of a derived class contained a nested class with a computed class member involving asuper
property access on the derived class:The compiler could previously generate incorrect code when a default-exported class contained a
super
property access inside a lowered static private class field:v0.14.29
Compare Source
Fix a minification bug with a double-nested
if
inside a label followed byelse
(#2139)This fixes a minification bug that affects the edge case where
if
is followed byelse
and theif
contains a label that contains a nestedif
. Normally esbuild's AST printer automatically wraps the body of a single-statementif
in braces to avoid the "dangling else"if
/else
ambiguity common to C-like languages (where theelse
accidentally becomes associated with the innerif
instead of the outerif
). However, I was missing automatic wrapping of label statements, which did not have test coverage because they are a rarely-used feature. This release fixes the bug:Fix edge case regarding
baseUrl
andpaths
intsconfig.json
(#2119)In
tsconfig.json
, TypeScript forbids non-relative values insidepaths
ifbaseUrl
is not present, and esbuild does too. However, TypeScript checked this after the entiretsconfig.json
hierarchy was parsed while esbuild incorrectly checked this immediately when parsing the file containing thepaths
map. This caused incorrect warnings to be generated fortsconfig.json
files that specify abaseUrl
value and that inherit apaths
value from anextends
clause. Now esbuild will only check for non-relativepaths
values after the entire hierarchy has been parsed to avoid generating incorrect warnings.Better handle errors where the esbuild binary executable is corrupted or missing (#2129)
If the esbuild binary executable is corrupted or missing, previously there was one situation where esbuild's JavaScript API could hang instead of generating an error. This release changes esbuild's library code to generate an error instead in this case.
v0.14.28
Compare Source
Add support for some new CSS rules (#2115, #2116, #2117)
This release adds support for
@font-palette-values
,@counter-style
, and@font-feature-values
. This means esbuild will now pretty-print and minify these rules better since it now better understands the internal structure of these rules:Upgrade to Go 1.18.0 (#2105)
Binary executables for this version are now published with Go version 1.18.0. The Go release notes say that the linker generates smaller binaries and that on 64-bit ARM chips, compiled binaries run around 10% faster. On an M1 MacBook Pro, esbuild's benchmark runs approximately 8% faster than before and the binary executable is approximately 4% smaller than before.
This also fixes a regression from version 0.14.26 of esbuild where the browser builds of the
esbuild-wasm
package could fail to be bundled due to the use of built-in node libraries. The primary WebAssembly shim for Go 1.18.0 no longer uses built-in node libraries.v0.14.27
Compare Source
Avoid generating an enumerable
default
import for CommonJS files in Babel mode (#2097)Importing a CommonJS module into an ES module can be done in two different ways. In node mode the
default
import is always set tomodule.exports
, while in Babel mode thedefault
import passes through tomodule.exports.default
instead. Node mode is triggered when the importing file ends in.mjs
, hastype: "module"
in itspackage.json
file, or the imported module does not have a__esModule
marker.Previously esbuild always created the forwarding
default
import in Babel mode, even ifmodule.exports
had no property calleddefault
. This was problematic because the getter nameddefault
still showed up as a property on the imported namespace object, and could potentially interfere with code that iterated over the properties of the imported namespace object. With this release the getter nameddefault
will now only be added in Babel mode if thedefault
property exists at the time of the import.Fix a circular import edge case regarding ESM-to-CommonJS conversion (#1894, #2059)
This fixes a regression that was introduced in version 0.14.5 of esbuild. Ever since that version, esbuild now creates two separate export objects when you convert an ES module file into a CommonJS module: one for ES modules and one for CommonJS modules. The one for CommonJS modules is written to
module.exports
and exported from the file, and the one for ES modules is internal and can be accessed by bundling code that imports the entry point (for example, the entry point might import itself to be able to inspect its own exports).The reason for these two separate export objects is that CommonJS modules are supposed to see a special export called
__esModule
which indicates that the module used to be an ES module, while ES modules are not supposed to see any automatically-added export named__esModule
. This matters for real-world code both because people sometimes iterate over the properties of ES module export namespace objects and because some people write ES module code containing their own exports named__esModule
that they expect other ES module code to be able to read.However, this change to split exports into two separate objects broke ES module re-exports in the edge case where the imported module is involved in an import cycle. This happened because the CommonJS
module.exports
object was no longer mutated as exports were added. Instead it was being initialized at the end of the generated file after the import statements to other modules (which are converted intorequire()
calls). This release changesmodule.exports
initialization to happen earlier in the file and then double-writes further exports to both the ES module and CommonJS module export objects.This fix was contributed by @indutny.
v0.14.26
Compare Source
Fix a tree shaking regression regarding
var
declarations (#2080, #2085, #2098, #2099)Version 0.14.8 of esbuild enabled removal of duplicate function declarations when minification is enabled (see #610):
This transformation is safe because function declarations are "hoisted" in JavaScript, which means they are all done first before any other code is evaluted. This means the last function declaration will overwrite all previous function declarations with the same name.
However, this introduced an unintentional regression for
var
declarations in which all but the last declaration was dropped if tree-shaking was enabled. This only happens for top-levelvar
declarations that re-declare the same variable multiple times. This regression has now been fixed:This case now has test coverage.
Add support for parsing "instantiation expressions" from TypeScript 4.7 (#2038)
The upcoming version of TypeScript now lets you specify
<...>
type parameters on a JavaScript identifier without using a call expression:With this release, esbuild can now parse these new type annotations. This feature was contributed by @g-plane.
Avoid
new Function
in esbuild's library code (#2081)Some JavaScript environments such as Cloudflare Workers or Deno Deploy don't allow
new Function
because they disallow dynamic JavaScript evaluation. Previously esbuild's WebAssembly-based library used this to construct the WebAssembly worker function. With this release, the code is now inlined without usingnew Function
so it will be able to run even when this restriction is in place.Drop superfluous
__name()
calls (#2062)When the
--keep-names
option is specified, esbuild inserts calls to a__name
helper function to ensure that the.name
property on function and class objects remains consistent even if the function or class name is renamed to avoid a name collision or because name minification is enabled. With this release, esbuild will now try to omit these calls to the__name
helper function when the name of the function or class object was not renamed during the linking process after all:Notice how one of the calls to
__name
is now no longer printed. This change was contributed by @indutny.v0.14.25
Compare Source
Reduce minification of CSS transforms to avoid Safari bugs (#2057)
In Safari, applying a 3D CSS transform to an element can cause it to render in a different order than applying a 2D CSS transform even if the transformation matrix is identical. I believe this is a bug in Safari because the CSS
transform
specification doesn't seem to distinguish between 2D and 3D transforms as far as rendering order:This bug means that minifying a 3D transform into a 2D transform must be avoided even though it's a valid transformation because it can cause rendering differences in Safari. Previously esbuild sometimes minified 3D CSS transforms into 2D CSS transforms but with this release, esbuild will no longer do that:
Minification now takes advantage of the
?.
operatorThis adds new code minification rules that shorten code with the
?.
optional chaining operator when the result is equivalent:This only takes effect when minification is enabled and when the configured target environment is known to support the optional chaining operator. As always, make sure to set
--target=
to the appropriate language target if you are running the minified code in an environment that doesn't support the latest JavaScript features.Add source mapping information for some non-executable tokens (#1448)
Code coverage tools can generate reports that tell you if any code exists that has not been run (or "covered") during your tests. You can use this information to add additional tests for code that isn't currently covered.
Some popular JavaScript code coverage tools have bugs where they incorrectly consider lines without any executable code as uncovered, even though there's no test you could possibly write that would cause those lines to be executed. For example, they apparently complain about the lines that only contain the trailing
}
token of an object literal.With this release, esbuild now generates source mappings for some of these trailing non-executable tokens. This may not successfully work around bugs in code coverage tools because there are many non-executable tokens in JavaScript and esbuild doesn't map them all (the drawback of mapping these extra tokens is that esbuild will use more memory, build more slowly, and output a bigger source map). The true solution is to fix the bugs in the code coverage tools in the first place.
Fall back to WebAssembly on Android x64 (#2068)
Go's compiler supports trivial cross-compiling to almost all platforms without installing any additional software other than the Go compiler itself. This has made it very easy for esbuild to publish native binary executables for many platforms. However, it strangely doesn't support cross-compiling to Android x64 without installing the Android build tools. So instead of publishing a native esbuild binary executable to npm, this release publishes a WebAssembly fallback build. This is essentially the same as the
esbuild-wasm
package but it's installed automatically when you install theesbuild
package on Android x64. So packages that depend on theesbuild
package should now work on Android x64. If you want to use a native binary executable of esbuild on Android x64, you may be able to build it yourself from source after installing the Android build tools.Update to Go 1.17.8
The version of the Go compiler used to compile esbuild has been upgraded from Go 1.17.7 to Go 1.17.8, which fixes the RISC-V 64-bit build. Compiler optimizations for the RISC-V 64-bit build have now been re-enabled.
v0.14.24
Compare Source
Allow
es2022
as a target environment (#2012)TypeScript recently added support for
es2022
as a compilation target so esbuild now supports this too. Support for this is preliminary as there is no published ES2022 specification yet (i.e. https://tc39.es/ecma262/2021/ exists but https://tc39.es/ecma262/2022/ is a 404 error). The meaning of esbuild'ses2022
target may change in the future when the specification is finalized. Right now I have made thees2022
target enable support for the syntax-related finished proposals that are marked as2022
:I have also included the "arbitrary module namespace names" feature since I'm guessing it will end up in the ES2022 specification (this syntax feature was added to the specification without a proposal). TypeScript has not added support for this yet.
Match
define
to strings in index expressions (#2050)With this release, configuring
--define:foo.bar=baz
now matches and replaces bothfoo.bar
andfoo['bar']
expressions in the original source code. This is necessary for people who have enabled TypeScript'snoPropertyAccessFromIndexSignature
feature, which prevents you from using normal property access syntax on a type with an index signature such as in the following code:Previously esbuild would generate the following output with
--define:foo.bar=baz
:Now esbuild will generate the following output instead:
Add
--mangle-quoted
to mangle quoted properties (#218)The
--mangle-props=
flag tells esbuild to automatically rename all properties matching the provided regular expression to shorter names to save space. Previously esbuild never modified the contents of string literals. In particular,--mangle-props=_
would manglefoo._bar
but notfoo['_bar']
. There are some coding patterns where renaming quoted property names is desirable, such as when using TypeScript'snoPropertyAccessFromIndexSignature
feature or when using TypeScript's discriminated union narrowing behavior:The
'_foo' in value
check tells TypeScript to narrow the type ofvalue
toFoo
in the true branch and toBar
in the false branch. Previously esbuild didn't mangle the property name'_foo'
because it was inside a string literal. With this release, you can now use--mangle-quoted
to also rename property names inside string literals:Parse and discard TypeScript
export as namespace
statements (#2070)TypeScript
.d.ts
type declaration files can sometimes contain statements of the formexport as namespace foo;
. I believe these serve to declare that the module adds a property of that name to the global object. You aren't supposed to feed.d.ts
files to esbuild so this normally doesn't matter, but sometimes esbuild can end up having to parse them. One such case is if you import a type-only package who'smain
field inpackage.json
is a.d.ts
file.Previously esbuild only allowed
export as namespace
statements inside adeclare
context:Now esbuild will also allow these statements outside of a
declare
context:These statements are still just ignored and discarded.
Strip import assertions from unrecognized
import()
expressions (#2036)The new "import assertions" JavaScript language feature adds an optional second argument to dynamic
import()
expressions, which esbuild does support. However, this optional argument must be stripped when targeting older JavaScript environments for which this second argument would be a syntax error. Previously esbuild failed to strip this second argument in cases when the first argument toimport()
wasn't a string literal. This problem is now fixed:Remove simplified statement-level literal expressions (#2063)
With this release, esbuild now removes simplified statement-level expressions if the simplified result is a literal expression even when minification is disabled. Previously this was only done when minification is enabled. This change was only made because some people are bothered by seeing top-level literal expressions. This change has no effect on code behavior.
Ignore
.d.ts
rules inpaths
intsconfig.json
files (#2074, #2075)TypeScript's
tsconfig.json
configuration file has apaths
field that lets you remap import paths to alternative files on the file system. This field is interpreted by esbuild during bundling so that esbuild's behavior matches that of the TypeScript type checker. However, people sometimes override import paths to JavaScript files to instead point to a.d.ts
TypeScript type declaration file for that JavaScript file. The intent of this is to just use the remapping for type information and not to actually import the.d.ts
file during the build.With this release, esbuild will now ignore rules in
paths
that result in a.d.ts
file during path resolution. This means code that does this should now be able to be bundled without modifying itstsconfig.json
file to remove the.d.ts
rule. This change was contributed by @magic-akari.Disable Go compiler optimizations for the Linux RISC-V 64bit build (#2035)
Go's RISC-V 64bit compiler target has a fatal compiler optimization bug that causes esbuild to crash when it's run: https://github.com/golang/go/issues/51101. As a temporary workaround until a version of the Go compiler with the fix is published, Go compiler optimizations have been disabled for RISC-V. The 7.7mb esbuild binary executable for RISC-V is now 8.7mb instead. This workaround was contributed by @piggynl.
v0.14.23
Compare Source
Update feature database to indicate that node 16.14+ supports import assertions (#2030)
Node versions 16.14 and above now support import assertions according to these release notes. This release updates esbuild's internal feature compatibility database with this information, so esbuild no longer strips import assertions with
--target=node16.14
:Basic support for CSS
@layer
rules (#2027)This adds basic parsing support for a new CSS feature called
@layer
that changes how the CSS cascade works. Adding parsing support for this rule to esbuild means esbuild can now minify the contents of@layer
rules:You can read more about
@layer
here:Note that the support added in this release is only for parsing and printing
@layer
rules. The bundler does not yet know about these rules and bundling with@layer
may result in behavior changes since these new rules have unusual ordering constraints that behave differently than all other CSS rules. Specifically the order is derived from the first instance while with every other CSS rule, the order is derived from the last instance.v0.14.22
Compare Source
Preserve whitespace for token lists that look like CSS variable declarations (#2020)
Previously esbuild removed the whitespace after the CSS variable declaration in the following CSS:
However, that broke rendering in Chrome as it caused Chrome to ignore the entire rule. This did not break rendering in Firefox and Safari, so there's a browser bug either with Chrome or with both Firefox and Safari. In any case, esbuild now preserves whitespace after the CSS variable declaration in this ca
Configuration
📅 Schedule: At any time (no schedule defined).
🚦 Automerge: Disabled by config. Please merge this manually once you are satisfied.
♻ Rebasing: Whenever PR becomes conflicted, 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.