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.29.3
->0.30.1
6.0.0
->6.0.1
4.2.0
->4.3.4
^0.13.4
->0.14.0
0.12.8
->0.12.17
11.0.3
->11.0.4
^7.2.0
->7.5.0
8.2.1
->8.4.0
2.3.1
->2.3.2
4.3.2
->4.3.5
Release Notes
ampproject/worker-dom
v0.30.1
Compare Source
95bb805
35139ef
v0.30.0
Compare Source
5d4d4c9
b1f1658
f5df3c3
af09257
1f7faa0
f627793
b4a1b33
8fe7039
471afef
92eed67
chaijs/chai
v4.3.4
Compare Source
This fixes broken inspect behavior with bigints (#1321) (#1383) thanks @vapier
v4.3.3
Compare Source
This reintroduces
Assertion
as an export in the mjs file. See chaijs/chai#1378 & chaijs/chai#1375v4.3.2
Compare Source
This fixes a regression in IE11. See chaijs/chai#1380 & chaijs/chai#1379
v4.3.1
Compare Source
This releases fixed an engine incompatibility with 4.3.0
The 4.x.x series of releases will be compatible with Node 4.0. Please report any errors found in Node 4 as bugs, and they will be fixed.
The 5.x.x series, when released, will drop support for Node 4.0
This fix also ensures
pathval
is updated to1.1.1
to fix CVE-2020-7751v4.3.0
Compare Source
This is a minor release.
Not many changes have got in since the last release but this one contains a very important change (#1257) which will allow
jest
users to get better diffs. From this release onwards,jest
users will be able to see which operator was used in their diffs. Theoperator
is a property of theAssertionError
thrown when assertions fail. This flag indicates what kind of comparison was made.This is also an important change for plugin maintainers. Plugin maintainers will now have access to the
operator
flag, which they can have access to through an
utilmethod called
getOperator`.Thanks to all the amazing people that contributed to this release.
New Features
contain.oneOf
to take an array of possible values (@voliva)closeTo
error message will now inform the user when adelta
is required (@eouw0o83hf)Docs
Tests
useProxy
config is checked inoverwriteProperty
(@vieiralucas)contain.oneOf
(@voliva )Chores
GoogleChrome/chrome-launcher
v0.14.0
Compare Source
ac1f4aff
move to minimum node 12; removerimraf
(#237)dec646c4
deps: removemkdirp
forfs.mkdirSync
(#234)83ab178a
update minimum node version (#222)a5f6eb2f
add additional chrome flags (#227)3a7c9610
reword unset-CHROME_PATH
error messageb1b8dc74
rename disabledTranslateUI
toTranslate
to match Chrome (#225)beb41360
chore: update dependencies and test targets (#221)df9d564a
tests: migrate from travis to github actions (#228)673da08b
tests: add mac/win bots to ci (#232)a700ae0c
docs: fix readme'sgetInstallations()
section (#212)chrome-flags-for-tools.md
update4b98587d
massive update and refactor (#226)e45b100f
minor tweaks to headless and others3a90c21b
fix links8429ca93
add feature flags description21db5f9f
even more documented flags (#231)evanw/esbuild
v0.12.17
Compare Source
Fix a bug with private fields and logical assignment operators (#1418)
This release fixes a bug where code using private fields in combination with logical assignment operators was transformed incorrectly if the target environment supported logical assignment operators but not private fields. Since logical assignment operators are assignment operators, the entire operator must be transformed even if the operator is supported. This should now work correctly:
Fix a hoisting bug in the bundler (#1455)
This release fixes a bug where variables declared using
var
inside of top-levelfor
loop initializers were not hoisted inside lazily-initialized ES modules (such as those that are generated when bundling code that loads an ES module usingrequire
). This meant that hoisted function declarations incorrectly didn't have access to these loop variables:Old output (incorrect):
New output (correct):
Fix a code generation bug for private methods (#1424)
This release fixes a bug where when private methods are transformed and the target environment is one that supports private methods (such as
esnext
), the member function name was uninitialized and took on the zero value by default. This resulted in the member function name becoming__create
instead of the correct name since that's the name of the symbol at index 0. Now esbuild always generates a private method symbol even when private methods are supported, so this is no longer an issue:The CLI now stops watch and serve mode when stdin is closed (#1449)
To facilitate esbuild being called from the Erlang VM, esbuild's command-line interface will now exit when in
--watch
or--serve
mode if stdin is closed. This change is necessary because the Erlang VM doesn't have an API for terminating a child process, so it instead closes stdin to indicate that the process is no longer needed.Note that this only happens when stdin is not a TTY (i.e. only when the CLI is being used non-interactively) to avoid disrupting the use case of manually moving esbuild to a background job using a Unix terminal.
This change was contributed by @josevalim.
v0.12.16
Compare Source
Remove warning about bad CSS
@
-rules (#1426)The CSS bundler built in to esbuild is only designed with real CSS in mind. Running other languages that compile down to CSS through esbuild without compiling them down to CSS first can be a bad idea since esbuild applies browser-style error recovery to invalid syntax and uses browser-style import order that other languages might not be expecting. This is why esbuild previously generated warnings when it encountered unknown CSS
@
-rules.However, some people want to run other non-CSS languages through esbuild's CSS bundler anyway. So with this release, esbuild will no longer generate any warnings if you do this. But keep in mind that doing this is still potentially unsafe. Depending on the input language, using esbuild's CSS bundler to bundle non-CSS code can still potentially alter the semantics of your code.
Allow
ES2021
intsconfig.json
(#1470)TypeScript recently added support for
ES2021
intsconfig.json
so esbuild now supports this too. This has the same effect as if you passed--target=es2021
to esbuild. Keep in mind that the value oftarget
intsconfig.json
is only respected if you did not pass a--target=
value to esbuild.Avoid using the
worker_threads
optimization in certain old node versions (#1462)The
worker_threads
optimization makes esbuild's synchronous API calls go much faster than they would otherwise. However, it turns out this optimization cannot be used in certain node versions older thanv12.17.0
, where node throws an error when trying to create the worker. This optimization is now disabled in these scenarios.Note that these old node versions are currently in maintenance. I recommend upgrading to a modern version of node if run-time performance is important to you.
Paths starting with
node:
are implicitly external when bundling for node (#1466)This replicates a new node feature where you can prefix an import path with
node:
to load a native node module by that name (such asimport fs from "node:fs/promises"
). These paths also have special behavior:With this release, esbuild's built-in resolver will now automatically consider all import paths starting with
node:
as external. This new behavior is only active when the current platform is set to node such as with--platform=node
. If you need to customize this behavior, you can write a plugin to intercept these paths and treat them differently.Consider
\
and/
to be the same in file paths (#1459)On Windows, there are many different file paths that can refer to the same underlying file. Windows uses a case-insensitive file system so for example
foo.js
andFoo.js
are the same file. When bundling, esbuild needs to treat both of these paths as the same to avoid incorrectly bundling the file twice. This is case is already handled by identifying files by their lower-case file path.The case that wasn't being handled is the fact that Windows supports two different path separators,
/
and\
, both of which mean the same thing. For examplefoo/bar.js
andfoo\bar.js
are the same file. With this release, this case is also handled by esbuild. Files that are imported in multiple places with inconsistent path separators will now be considered the same file instead of bundling the file multiple times.v0.12.15
Compare Source
Fix a bug with
var()
in CSS color lowering (#1421)This release fixes a bug with esbuild's handling of the
rgb
andhsl
color functions when they containvar()
. Eachvar()
token sequence can be substituted for any number of tokens including zero or more than one, but previously esbuild's output was only correct if eachvar()
inside ofrgb
orhsl
contained exactly one token. With this release, esbuild will now not attempt to transform newer CSS color syntax to older CSS color syntax if it containsvar()
:The bug with the old output above happened because esbuild considered the arguments to
hsl
as matching the patternhsl(h s l)
which is the new space-separated form allowed by CSS Color Module Level 4. Then esbuild tried to convert this to the formhsl(h, s, l)
which is more widely supported by older browsers. But this substitution doesn't work in the presence ofvar()
, so it has now been disabled in that case.v0.12.14
Compare Source
Fix the
file
loader with custom namespaces (#1404)This fixes a regression from version 0.12.12 where using a plugin to load an input file with the
file
loader in a custom namespace caused esbuild to write the contents of that input file to the path associated with that namespace instead of to a path inside of the output directory. With this release, thefile
loader should now always copy the file somewhere inside of the output directory.v0.12.13
Compare Source
Fix using JS synchronous API from from non-main threads (#1406)
This release fixes an issue with the new implementation of the synchronous JS API calls (
transformSync
andbuildSync
) when they are used from a thread other than the main thread. The problem happened because esbuild's new implementation uses node'sworker_threads
library internally and non-main threads were incorrectly assumed to be esbuild's internal thread instead of potentially another unrelated thread. Now esbuild's synchronous JS APIs should work correctly when called from non-main threads.v0.12.12
Compare Source
Fix
file
loader import paths when subdirectories are present (#1044)Using the
file
loader for a file type causes importing affected files to copy the file into the output directory and to embed the path to the copied file into the code that imported it. However, esbuild previously always embedded the path relative to the output directory itself. This is problematic when the importing code is generated within a subdirectory inside the output directory, since then the relative path is wrong. For example:This is output from the previous version of esbuild. The above asset reference in
out/example/entry.css
is wrong. The path should start with../
because the two files are in different directories.With this release, the asset references present in output files will now be the full relative path from the output file to the asset, so imports should now work correctly when the entry point is in a subdirectory within the output directory. This change affects asset reference paths in both CSS and JS output files.
Note that if you want asset reference paths to be independent of the subdirectory in which they reside, you can use the
--public-path
setting to provide the common path that all asset reference paths should be constructed relative to. Specifically--public-path=.
should bring back the old problematic behavior in case you need it.Add support for
[dir]
in--asset-names
(#1196)You can now use path templates such as
--asset-names=[dir]/[name]-[hash]
to copy the input directory structure of your asset files (i.e. input files loaded with thefile
loader) to the output directory. Here's an example:v0.12.11
Compare Source
Enable faster synchronous transforms with the JS API by default (#1000)
Currently the synchronous JavaScript API calls
transformSync
andbuildSync
spawn a new child process on every call. This is due to limitations with node'schild_process
API. Doing this meanstransformSync
andbuildSync
are much slower thantransform
andbuild
, which share the same child process across calls.This release improves the performance of
transformSync
andbuildSync
by up to 20x. It enables a hack where node'sworker_threads
API and atomics are used to block the main thread while asynchronous communication with a single long-lived child process happens in a worker. Previously this was only enabled when theESBUILD_WORKER_THREADS
environment variable was set to1
. But this experiment has been available for a while (since version 0.9.6) without any reported issues. Now this hack will be enabled by default. It can be disabled by settingESBUILD_WORKER_THREADS
to0
before running node.Fix nested output directories with WebAssembly on Windows (#1399)
Many functions in Go's standard library have a bug where they do not work on Windows when using Go with WebAssembly. This is a long-standing bug and is a fault with the design of the standard library, so it's unlikely to be fixed. Basically Go's standard library is designed to bake "Windows or not" decision into the compiled executable, but WebAssembly is platform-independent which makes "Windows or not" is a run-time decision instead of a compile-time decision. Oops.
I have been working around this by trying to avoid using path-related functions in the Go standard library and doing all path manipulation by myself instead. This involved completely replacing Go's
path/filepath
library. However, I missed theos.MkdirAll
function which is also does path manipulation but is outside of thepath/filepath
package. This meant that nested output directories failed to be created on Windows, which caused a build error. This problem only affected theesbuild-wasm
package.This release manually reimplements nested output directory creation to work around this bug in the Go standard library. So nested output directories should now work on Windows with the
esbuild-wasm
package.v0.12.10
Compare Source
Add a target for ES2021
It's now possible to use
--target=es2021
to target the newly-released JavaScript version ES2021. The only difference between that and--target=es2020
is that logical assignment operators such asa ||= b
are not converted to regular assignment operators such asa || (a = b)
.Minify the syntax
Infinity
to1 / 0
(#1385)The
--minify-syntax
flag (automatically enabled by--minify
) will now minify the expressionInfinity
to1 / 0
, which uses fewer bytes:This change was contributed by @Gusted.
Minify syntax in the CSS
transform
property (#1390)This release includes various size reductions for CSS transform matrix syntax when minification is enabled:
The
translate3d
totranslateZ
conversion was contributed by @steambap.Support for the case-sensitive flag in CSS attribute selectors (#1397)
You can now use the case-sensitive CSS attribute selector flag
s
such as in[type="a" s] { list-style: lower-alpha; }
. Previously doing this caused a warning about unrecognized syntax.v0.12.9
Compare Source
Allow
this
with--define
(#1361)You can now override the default value of top-level
this
with the--define
feature. Top-levelthis
defaults to beingundefined
in ECMAScript modules andexports
in CommonJS modules. For example:Note that overriding what top-level
this
is will likely break code that uses it correctly. So this new feature is only useful in certain cases.Fix CSS minification issue with
!important
and duplicate declarations (#1372)Previously CSS with duplicate declarations for the same property where the first one was marked with
!important
was sometimes minified incorrectly. For example:This was incorrectly minified as
.selector{padding:0}
. The bug affected three properties:padding
,margin
, andborder-radius
. With this release, this code will now be minified as.selector{padding:10px!important;padding:0}
instead which means there is no longer a difference between minified and non-minified code in this case.sindresorhus/globby
v11.0.4
Compare Source
objectMode
option in the TypeScript types (#178)a08264f
GoogleChrome/lighthouse
v7.5.0
Compare Source
Full Changelog
We expect this release to ship in the DevTools of Chrome 92, and to PageSpeed Insights within 2 weeks.
New contributors
Thanks to our new contributor 👽🐷🐰🐯🐻!
Notable Changes
We are releasing the Lighthouse Treemap!
You may already be familiar with treemaps thanks to webtreemap (which we use!) or source-map-explorer. With Lighthouse Treemap, you'll be able to view all the JavaScript bundles on your page easily from a Lighthouse report, in addition to some insights that may help reduce the amount of JavaScript on a page. The only requirement is that source maps are accessible (either publicly, or securely from the same computer that is running the Lighthouse audit).
We even collect code coverage data from Chrome, and extrapolate the coverage of individual modules in a bundle. Note: this only takes into account a cold-load: code only used after user interaction will be marked as unused. Stay tuned for a future release, which will enable you to configure user flows and capture even more accurate performance insights.
If we detect a large module included by multiple bundles, we'll alert you of that too.
You can access Lighthouse Treemap from the report:
Currently, only reports generated with the Lighthouse Node CLI will connect to the Lighthouse Treemap App. This functionality will be in DevTools and PageSpeed Insights as of Lighthouse v8.0.
Demo
Core
Fraggle Rock
Support for auditing user flows (#11313)
Report
Deps
I18n
Docs
Tests
Misc
v7.4.0
Compare Source
Full Changelog
We expect this release to ship in the DevTools of Chrome 92, and to PageSpeed Insights within 2 weeks.
New contributors
Thanks to our new contributors 👽🐷🐰🐯🐻!
Notable Changes
Core
Fraggle Rock
Support for auditing user flows (#11313)
CLI
Report
Deps
I18n
Docs
Tests
Misc
v7.3.0
Compare Source
Full Changelog
We expect this release to ship in the DevTools of Chrome 91, and to PageSpeed Insights within 2 weeks.
New contributors
Thanks to our new contributor 👽🐷🐰🐯🐻!
New Audits
Core
CLI
Report
Deps
I18n
Docs
Tests
Misc
mochajs/mocha
v8.4.0
Compare Source
🎉 Enhancements
🐛 Fixes
📖 Documentation
options.require
to Mocha constructor forroot hook
plugins on parallel runs (@juergba)top-level await
and ESM test files (@juergba)Also thanks to @outsideris for various improvements on our GH actions workflows.
v8.3.2
Compare Source
🐛 Fixes
require
interface (@alexander-fenster)📖 Documentation
v8.3.1
Compare Source
🐛 Fixes
EvalError
caused by regenerator-runtime ([Configuration
📅 Schedule: "before 3am on Monday" (UTC).
🚦 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 WhiteSource Renovate. View repository job log here.