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
Update all #42
Open
renovate
wants to merge
1
commit into
main
Choose a base branch
from
renovate/all
base: main
Could not load branches
Branch not found: {{ refName }}
Could not load tags
Nothing to show
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.
Open
Update all #42
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/all
branch
5 times, most recently
from
March 6, 2022 17:46
2c17322
to
d2b4437
Compare
renovate
bot
force-pushed
the
renovate/all
branch
5 times, most recently
from
March 16, 2022 05:20
ba44c99
to
dcae38d
Compare
renovate
bot
force-pushed
the
renovate/all
branch
4 times, most recently
from
March 26, 2022 06:26
837370d
to
33ebaea
Compare
renovate
bot
force-pushed
the
renovate/all
branch
5 times, most recently
from
April 6, 2022 03:41
c5a5e99
to
f16b941
Compare
renovate
bot
force-pushed
the
renovate/all
branch
4 times, most recently
from
April 12, 2022 10:41
57489e8
to
dab1635
Compare
renovate
bot
force-pushed
the
renovate/all
branch
from
April 24, 2022 21:29
dab1635
to
d501832
Compare
renovate
bot
force-pushed
the
renovate/all
branch
from
May 15, 2022 21:58
d501832
to
3e93642
Compare
renovate
bot
force-pushed
the
renovate/all
branch
2 times, most recently
from
June 23, 2022 22:05
c946304
to
3d1daff
Compare
renovate
bot
force-pushed
the
renovate/all
branch
from
September 25, 2022 18:20
3d1daff
to
a1ae44e
Compare
renovate
bot
force-pushed
the
renovate/all
branch
from
November 20, 2022 20:59
a1ae44e
to
a8ca9fe
Compare
renovate
bot
force-pushed
the
renovate/all
branch
from
March 16, 2023 18:11
a8ca9fe
to
a41f43f
Compare
renovate
bot
force-pushed
the
renovate/all
branch
4 times, most recently
from
August 14, 2023 05:06
f832675
to
dd5d84f
Compare
renovate
bot
force-pushed
the
renovate/all
branch
from
August 24, 2023 15:09
dd5d84f
to
eed9460
Compare
renovate
bot
force-pushed
the
renovate/all
branch
from
September 14, 2023 01:30
eed9460
to
796605e
Compare
renovate
bot
force-pushed
the
renovate/all
branch
3 times, most recently
from
September 28, 2023 10:51
7a01f39
to
8000c23
Compare
renovate
bot
force-pushed
the
renovate/all
branch
from
October 17, 2023 07:41
8000c23
to
d86ee27
Compare
renovate
bot
force-pushed
the
renovate/all
branch
2 times, most recently
from
November 21, 2023 03:40
5b76923
to
edfa024
Compare
renovate
bot
force-pushed
the
renovate/all
branch
from
November 27, 2023 02:21
edfa024
to
a0fa905
Compare
renovate
bot
force-pushed
the
renovate/all
branch
from
December 10, 2023 08:44
a0fa905
to
5d78a78
Compare
renovate
bot
force-pushed
the
renovate/all
branch
from
December 19, 2023 01:06
5d78a78
to
7917d1f
Compare
renovate
bot
force-pushed
the
renovate/all
branch
2 times, most recently
from
January 5, 2024 13:48
d4641a3
to
c302c9f
Compare
renovate
bot
force-pushed
the
renovate/all
branch
from
January 12, 2024 16:25
c302c9f
to
8fb98b9
Compare
renovate
bot
force-pushed
the
renovate/all
branch
2 times, most recently
from
January 27, 2024 17:48
986beed
to
16140c6
Compare
renovate
bot
force-pushed
the
renovate/all
branch
from
February 19, 2024 09:41
16140c6
to
5e3fdf2
Compare
renovate
bot
force-pushed
the
renovate/all
branch
from
February 29, 2024 14:52
5e3fdf2
to
b5c7a56
Compare
renovate
bot
force-pushed
the
renovate/all
branch
3 times, most recently
from
March 21, 2024 00:19
a36091d
to
a3af94f
Compare
renovate
bot
force-pushed
the
renovate/all
branch
from
March 25, 2024 18:02
a3af94f
to
ffc3a99
Compare
renovate
bot
force-pushed
the
renovate/all
branch
2 times, most recently
from
May 7, 2024 17:14
8cc7ac7
to
e0eefa9
Compare
renovate
bot
force-pushed
the
renovate/all
branch
from
May 12, 2024 23:19
e0eefa9
to
48c1565
Compare
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Labels
None yet
0 participants
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.33.0
->0.35.0
4.1.1
->4.1.3
4.0.1
->4.3.3
4.3.6
->4.4.1
0.15.0
->0.15.2
0.14.21
->0.21.2
13.1.1
->13.2.2
9.3.1
->9.6.8
9.2.0
->9.2.2
7.6.0
->7.7.0
2.5.1
->2.8.8
4.5.5
->4.9.5
Release Notes
ampproject/worker-dom (@ampproject/worker-dom)
v0.35.0
Compare Source
v0.34.0
Compare Source
d27b429
a6bcd6f
9cff888
doowb/ansi-colors (ansi-colors)
v4.1.3
Compare Source
v4.1.2
Compare Source
avajs/ava (ava)
v4.3.3
Compare Source
Add compatibility with Node.js 18.8, thanks @Brooooooklyn #3091.
Full Changelog: avajs/ava@v4.3.1...v4.3.3
v4.3.2
Compare Source
v4.3.1
Compare Source
What's Changed
New Contributors
Full Changelog: avajs/ava@v4.3.0...v4.3.1
v4.3.0
Compare Source
What's Changed
throws
andthrowsAsync
assertions now take a function to test error messages, by @il3ven in https://github.com/avajs/ava/pull/2995t.log()
messages, by @il3ven in https://github.com/avajs/ava/pull/3013Full Changelog: avajs/ava@v4.2.0...v4.3.0
v4.2.0
Compare Source
What's Changed
New Contributors
Full Changelog: avajs/ava@v4.1.0...v4.2.0
v4.1.0
Compare Source
New features
sortTestFiles()
inava.config.js
files by @erezrokah in https://github.com/avajs/ava/pull/2968ava.config.json
files are encountered by @razor-x in https://github.com/avajs/ava/pull/2962deepEqual
assertion by @RebeccaStevens in https://github.com/avajs/ava/pull/2969Fixes
ava --version
works again by @novemberborn in https://github.com/avajs/ava/pull/2961New Contributors
Full Changelog: avajs/ava@v4.0.1...v4.1.0
chaijs/chai (chai)
v4.4.1
Compare Source
What's Changed
??
for node compat by @43081j in https://github.com/chaijs/chai/pull/1574Full Changelog: chaijs/chai@v4.4.0...v4.4.1
v4.4.0
Compare Source
What's Changed
Full Changelog: chaijs/chai@v4.3.10...v4.4.0
v4.3.10
Compare Source
This release simply bumps all dependencies to their latest non-breaking versions.
What's Changed
Full Changelog: chaijs/chai@v4.3.9...v4.3.10
v4.3.9
Compare Source
Upgrade dependencies.
This release upgrades dependencies to address CVE-2023-43646 where a large function name can cause "catastrophic backtracking" (aka ReDOS attack) which can cause the test suite to hang.
Full Changelog: chaijs/chai@v4.3.8...v4.3.9
v4.3.8
Compare Source
What's Changed
New Contributors
Full Changelog: chaijs/chai@v4.3.7...v4.3.8
v4.3.7
Compare Source
What's Changed
Full Changelog: chaijs/chai@v4.3.6...v4.3.7
GoogleChrome/chrome-launcher (chrome-launcher)
v0.15.2
Compare Source
76b6a13c
Update logLevel option typing (#295)60044483
Update headless=chrome flag to headless=new (#290)b041125a
log when connection to existing chrome found for requested port (#291)f64a7d89
docs(flags): fix description of mock-keychain flagc753ba08
use updating node versions in CI (#286)8d1d85dc
docs(flags): adjust grouping. add in several features (#283)471a97c7
flags: disable optimization guide and media router (#282)83f08461
docs(flags): add disable-features=MediaRouter which is surprisingly active346b3c2c
rename master branch references to main (#280)f618e7e5
docs: a few additions to the flags docc36bd8dc
docs: add OptimizationHints to flags1cbf8b9a
Make LaunchedChrome.kill sync (#269)v0.15.1
Compare Source
3724165a
make launcher.kill() synchronous (#268)3561350a
revise taskkill procedure on windows (#267)690ae983
add lighthouse smoketests (windows) to CI (#265)279577fd
docs(chrome-flags-for-tools): add link to overview of features (#235)ff91c18b
fix: usewslpath
to resolve Windows paths (#200)30755cde
test: run latest versions of node in CI (#257)evanw/esbuild (esbuild)
v0.21.2
Compare Source
Correct
this
in field and accessor decorators (#3761)This release changes the value of
this
in initializers for class field and accessor decorators from the module-levelthis
value to the appropriatethis
value for the decorated element (either the class or the instance). It was previously incorrect due to lack of test coverage. Here's an example of a decorator that doesn't work without this change:Allow
es2023
as a target environment (#3762)TypeScript recently added
es2023
as a compilation target, so esbuild now supports this too. There is no difference between a target ofes2022
andes2023
as far as esbuild is concerned since the 2023 edition of JavaScript doesn't introduce any new syntax features.v0.21.1
Compare Source
Fix a regression with
--keep-names
(#3756)The previous release introduced a regression with the
--keep-names
setting and object literals withget
/set
accessor methods, in which case the generated code contained syntax errors. This release fixes the regression:v0.21.0
Compare Source
This release doesn't contain any deliberately-breaking changes. However, it contains a very complex new feature and while all of esbuild's tests pass, I would not be surprised if an important edge case turns out to be broken. So I'm releasing this as a breaking change release to avoid causing any trouble. As usual, make sure to test your code when you upgrade.
Implement the JavaScript decorators proposal (#104)
With this release, esbuild now contains an implementation of the upcoming JavaScript decorators proposal. This is the same feature that shipped in TypeScript 5.0 and has been highly-requested on esbuild's issue tracker. You can read more about them in that blog post and in this other (now slightly outdated) extensive blog post here: https://2ality.com/2022/10/javascript-decorators.html. Here's a quick example:
Note that this feature is different than the existing "TypeScript experimental decorators" feature that esbuild already implements. It uses similar syntax but behaves very differently, and the two are not compatible (although it's sometimes possible to write decorators that work with both). TypeScript experimental decorators will still be supported by esbuild going forward as they have been around for a long time, are very widely used, and let you do certain things that are not possible with JavaScript decorators (such as decorating function parameters). By default esbuild will parse and transform JavaScript decorators, but you can tell esbuild to parse and transform TypeScript experimental decorators instead by setting
"experimentalDecorators": true
in yourtsconfig.json
file.Probably at least half of the work for this feature went into creating a test suite that exercises many of the proposal's edge cases: https://github.com/evanw/decorator-tests. It has given me a reasonable level of confidence that esbuild's initial implementation is acceptable. However, I don't have access to a significant sample of real code that uses JavaScript decorators. If you're currently using JavaScript decorators in a real code base, please try out esbuild's implementation and let me know if anything seems off.
This proposal has been in the works for a very long time (work began around 10 years ago in 2014) and it is finally getting close to becoming part of the JavaScript language. However, it's still a work in progress and isn't a part of JavaScript yet, so keep in mind that any code that uses JavaScript decorators may need to be updated as the feature continues to evolve. The decorators proposal is pretty close to its final form but it can and likely will undergo some small behavioral adjustments before it ends up becoming a part of the standard. If/when that happens, I will update esbuild's implementation to match the specification. I will not be supporting old versions of the specification.
Optimize the generated code for private methods
Previously when lowering private methods for old browsers, esbuild would generate one
WeakSet
for each private method. This mirrors similar logic for generating oneWeakSet
for each private field. Using a separateWeakMap
for private fields is necessary as their assignment can be observable:This prints
true false
because this partially-initialized instance has#x
but not#y
. In other words, it's not true that all class instances will always have all of their private fields. However, the assignment of private methods to a class instance is not observable. In other words, it's true that all class instances will always have all of their private methods. This means esbuild can lower private methods into code where all methods share a singleWeakSet
, which is smaller, faster, and uses less memory. Other JavaScript processing tools such as the TypeScript compiler already make this optimization. Here's what this change looks like:Fix an obscure bug with lowering class members with computed property keys
When class members that use newer syntax features are transformed for older target environments, they sometimes need to be relocated. However, care must be taken to not reorder any side effects caused by computed property keys. For example, the following code must evaluate
a()
thenb()
thenc()
:Previously esbuild did this by shifting the computed property key forward to the next spot in the evaluation order. Classes evaluate all computed keys first and then all static class elements, so if the last computed key needs to be shifted, esbuild previously inserted a static block at start of the class body, ensuring it came before all other static class elements:
However, this could cause esbuild to accidentally generate a syntax error if the computed property key contains code that isn't allowed in a static block, such as an
await
expression. With this release, esbuild fixes this problem by shifting the computed property key backward to the previous spot in the evaluation order instead, which may push it into theextends
clause or even before the class itself:Fix some
--keep-names
edge casesThe
NamedEvaluation
syntax-directed operation in the JavaScript specification gives certain anonymous expressions aname
property depending on where they are in the syntax tree. For example, the following initializers convey aname
value:When you enable esbuild's
--keep-names
setting, esbuild generates additional code to represent thisNamedEvaluation
operation so that the value of thename
property persists even when the identifiers are renamed (e.g. due to minification).However, I recently learned that esbuild's implementation of
NamedEvaluation
is missing a few cases. Specifically esbuild was missing property definitions, class initializers, logical-assignment operators. These cases should now all be handled:v0.20.2
Compare Source
Support TypeScript experimental decorators on
abstract
class fields (#3684)With this release, you can now use TypeScript experimental decorators on
abstract
class fields. This was silently compiled incorrectly in esbuild 0.19.7 and below, and was an error from esbuild 0.19.8 to esbuild 0.20.1. Code such as the following should now work correctly:JSON loader now preserves
__proto__
properties (#3700)Copying JSON source code into a JavaScript file will change its meaning if a JSON object contains the
__proto__
key. A literal__proto__
property in a JavaScript object literal sets the prototype of the object instead of adding a property named__proto__
, while a literal__proto__
property in a JSON object literal just adds a property named__proto__
. With this release, esbuild will now work around this problem by converting JSON to JavaScript with a computed property key in this case:Improve dead code removal of
switch
statements (#3659)With this release, esbuild will now remove
switch
statements in branches when minifying if they are known to never be evaluated:Empty enums should behave like an object literal (#3657)
TypeScript allows you to create an empty enum and add properties to it at run time. While people usually use an empty object literal for this instead of a TypeScript enum, esbuild's enum transform didn't anticipate this use case and generated
undefined
instead of{}
for an empty enum. With this release, you can now use an empty enum to generate an empty object literal.Handle Yarn Plug'n'Play edge case with
tsconfig.json
(#3698)Previously a
tsconfig.json
file thatextends
another file in a package with anexports
map failed to work when Yarn's Plug'n'Play resolution was active. This edge case should work now starting with this release.Work around issues with Deno 1.31+ (#3682)
Version 0.20.0 of esbuild changed how the esbuild child process is run in esbuild's API for Deno. Previously it used
Deno.run
but that API is being removed in favor ofDeno.Command
. As part of this change, esbuild is now calling the newunref
function on esbuild's long-lived child process, which is supposed to allow Deno to exit when your code has finished running even though the child process is still around (previously you had to explicitly call esbuild'sstop()
function to terminate the child process for Deno to be able to exit).However, this introduced a problem for Deno's testing API which now fails some tests that use esbuild with
error: Promise resolution is still pending but the event loop has already resolved
. It's unclear to me why this is happening. The call tounref
was recommended by someone on the Deno core team, and calling Node's equivalentunref
API has been working fine for esbuild in Node for a long time. It could be that I'm using it incorrectly, or that there's some reference counting and/or garbage collection bug in Deno's internals, or that Deno'sunref
just works differently than Node'sunref
. In any case, it's not good for Deno tests that use esbuild to be failing.In this release, I am removing the call to
unref
to fix this issue. This means that you will now have to call esbuild'sstop()
function to allow Deno to exit, just like you did before esbuild version 0.20.0 when this regression was introduced.Note: This regression wasn't caught earlier because Deno doesn't seem to fail tests that have outstanding
setTimeout
calls, which esbuild's test harness was using to enforce a maximum test runtime. Adding asetTimeout
was allowing esbuild's Deno tests to succeed. So this regression doesn't necessarily apply to all people using tests in Deno.v0.20.1
Compare Source
Fix a bug with the CSS nesting transform (#3648)
This release fixes a bug with the CSS nesting transform for older browsers where the generated CSS could be incorrect if a selector list contained a pseudo element followed by another selector. The bug was caused by incorrectly mutating the parent rule's selector list when filtering out pseudo elements for the child rules:
Constant folding for JavaScript inequality operators (#3645)
This release introduces constant folding for the
< > <= >=
operators. The minifier will now replace these operators withtrue
orfalse
when both sides are compile-time numeric or string constants:Better handling of
__proto__
edge cases (#3651)JavaScript object literal syntax contains a special case where a non-computed property with a key of
__proto__
sets the prototype of the object. This does not apply to computed properties or to properties that use the shorthand property syntax introduced in ES6. Previously esbuild didn't correctly preserve the "sets the prototype" status of properties inside an object literal, meaning a property that sets the prototype could accidentally be transformed into one that doesn't and vice versa. This has now been fixed:Fix cross-platform non-determinism with CSS color space transformations (#3650)
The Go compiler takes advantage of "fused multiply and add" (FMA) instructions on certain processors which do the operation
x*y + z
without intermediate rounding. This causes esbuild's CSS color space math to differ on different processors (currentlyppc64le
ands390x
), which breaks esbuild's guarantee of deterministic output. To avoid this, esbuild's color space math now inserts afloat64()
cast around every single math operation. This tells the Go compiler not to use the FMA optimization.Fix a crash when resolving a path from a directory that doesn't exist (#3634)
This release fixes a regression where esbuild could crash when resolving an absolute path if the source directory for the path resolution operation doesn't exist. While this situation doesn't normally come up, it could come up when running esbuild concurrently with another operation that mutates the file system as esbuild is doing a build (such as using
git
to switch branches). The underlying problem was a regression that was introduced in version 0.18.0.v0.20.0
Compare Source
This release deliberately contains backwards-incompatible changes. To avoid automatically picking up releases like this, you should either be pinning the exact version of
esbuild
in yourpackage.json
file (recommended) or be using a version range syntax that only accepts patch upgrades such as^0.19.0
or~0.19.0
. See npm's documentation about semver for more information.This time there is only one breaking change, and it only matters for people using Deno. Deno tests that use esbuild will now fail unless you make the change described below.
Work around API deprecations in Deno 1.40.x (#3609, #3611)
Deno 1.40.0 was just released and introduced run-time warnings about certain APIs that esbuild uses. With this release, esbuild will work around these run-time warnings by using newer APIs if they are present and falling back to the original APIs otherwise. This should avoid the warnings without breaking compatibility with older versions of Deno.
Unfortunately, doing this introduces a breaking change. The newer child process APIs lack a way to synchronously terminate esbuild's child process, so calling
esbuild.stop()
from within a Deno test is no longer sufficient to prevent Deno from failing a test that uses esbuild's API (Deno fails tests that create a child process without killing it before the test ends). To work around this, esbuild'sstop()
function has been changed to return a promise, and you now have to changeesbuild.stop()
toawait esbuild.stop()
in all of your Deno tests.Reorder implicit file extensions within
node_modules
(#3341, #3608)In version 0.18.0, esbuild changed the behavior of implicit file extensions within
node_modules
directories (i.e. in published packages) to prefer.js
over.ts
even when the--resolve-extensions=
order prefers.ts
over.js
(which it does by default). However, doing that also accidentally made esbuild prefer.css
over.ts
, which caused problems for people that published packages containing both TypeScript and CSS in files with the same name.With this release, esbuild will reorder TypeScript file extensions immediately after the last JavaScript file extensions in the implicit file extension order instead of putting them at the end of the order. Specifically the default implicit file extension order is
.tsx,.ts,.jsx,.js,.css,.json
which used to become.jsx,.js,.css,.json,.tsx,.ts
innode_modules
directories. With this release it will now become.jsx,.js,.tsx,.ts,.css,.json
instead.Why even rewrite the implicit file extension order at all? One reason is because the
.js
file is more likely to behave correctly than the.ts
file. The behavior of the.ts
file may depend ontsconfig.json
and thetsconfig.json
file may not even be published, or may useextends
to refer to a basetsconfig.json
file that wasn't published. People can get into this situation when they forget to add all.ts
files to their.npmignore
file before publishing to npm. Picking.js
over.ts
helps make it more likely that resulting bundle will behave correctly.v0.19.12
Compare Source
The "preserve" JSX mode now preserves JSX text verbatim (#3605)
The JSX specification deliberately doesn't specify how JSX text is supposed to be interpreted and there is no canonical way to interpret JSX text. Two most popular interpretations are Babel and TypeScript. Yes they are different (esbuild deliberately follows TypeScript by the way).
Previously esbuild normalized text to the TypeScript interpretation when the "preserve" JSX mode is active. However, "preserve" should arguably reproduce the original JSX text verbatim so that whatever JSX transform runs after esbuild is free to interpret it however it wants. So with this release, esbuild will now pass JSX text through unmodified:
Allow JSX elements as JSX attribute values
JSX has an obscure feature where you can use JSX elements in attribute position without surrounding them with
{...}
. It looks like this:I think I originally didn't implement it even though it's part of the JSX specification because it previously didn't work in TypeScript (and potentially also in Babel?). However, support for it was silently added in TypeScript 4.8 without me noticing and Babel has also since fixed their bugs regarding this feature. So I'm adding it to esbuild too now that I know it's widely supported.
Keep in mind that there is some ongoing discussion about removing this feature from JSX. I agree that the syntax seems out of place (it does away with the elegance of "JSX is basically just XML with
{...}
escapes" for something arguably harder to read, which doesn't seem like a good trade-off), but it's in the specification and TypeScript and Babel both implement it so I'm going to have esbuild implement it too. However, I reserve the right to remove it from esbuild if it's ever removed from the specification in the future. So use it with caution.Fix a bug with TypeScript type parsing (#3574)
This release fixes a bug with esbuild's TypeScript parser where a conditional type containing a union type that ends with an infer type that ends with a constraint could fail to parse. This was caused by the "don't parse a conditional type" flag not getting passed through the union type parser. Here's an example of valid TypeScript code that previously failed to parse correctly:
v0.19.11
Compare Source
Fix TypeScript-specific class transform edge case (#3559)
The previous release introduced an optimization that avoided transforming
super()
in the class constructor for TypeScript code compiled withuseDefineForClassFields
set tofalse
if all class instance fields have no initializers. The rationale was that in this case, all class instance fields are omitted in the output so no changes to the constructor are needed. However, if all of this is the case and there are#private
instance fields with initializers, those private instance field initializers were still being moved into the constructor. This was problematic because they were being inserted before the call tosuper()
(sincesuper()
is now no longer transformed in that case). This release introduces an additional optimization that avoids moving the private instance field initializers into the constructor in this edge case, which generates smaller code, matches the TypeScript compiler's output more closely, and avoids this bug:Minifier: allow reording a primitive past a side-effect (#3568)
The minifier previously allowed reordering a side-effect past a primitive, but didn't handle the case of reordering a primitive past a side-effect. This additional case is now handled:
Minifier: consider properties named using known
Symbol
instances to be side-effect free (#3561)Many things in JavaScript can have side effects including property accesses and ToString operations, so using a symbol such as
Symbol.iterator
as a computed property name is not obviously side-effect free. This release adds a special case for knownSymbol
instances so that they are considered side-effect free when used as property names. For example, this class declaration will now be considered side-effect free:Provide the
stop()
API in node to exit esbuild's child process (#3558)You can now call
stop()
in esbuild's node API to exit esbuild's child process to reclaim the resources used. It only makes sense to do this for a long-lived node process when you know you will no longer be making any more esbuild API calls. It is not necessary to call this to allow node to exit, and it's advantageous to not call this in between calls to esbuild's API as sharing a single long-lived esbuild child process is more efficient than re-creating a new esbuild child process for every API call. This API call used to exist but was removed in version 0.9.0. This release adds it back due to a user request.v0.19.10
Compare Source
Fix glob imports in TypeScript files (#3319)
This release fixes a problem where bundling a TypeScript file containing a glob import could emit a call to a helper function that doesn't exist. The problem happened because esbuild's TypeScript transformation removes unused imports (which is required for correctness, as they may be type-only imports) and esbuild's glob import transformation wasn't correctly marking the imported helper function as used. This wasn't caught earlier because most of esbuild's glob import tests were written in JavaScript, not in TypeScript.
Fix `requ
Configuration
📅 Schedule: Branch creation - "before 4am on Monday" (UTC), Automerge - At any time (no schedule defined).
🚦 Automerge: Enabled.
♻ Rebasing: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox.
👻 Immortal: This PR will be recreated if closed unmerged. Get config help if that's undesired.
This PR has been generated by Mend Renovate. View repository job log here.