-
Notifications
You must be signed in to change notification settings - Fork 4
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
chore(deps): update dependency esbuild to v0.15.12 #608
Conversation
|
The latest updates on your projects. Learn more about Vercel for Git ↗︎
|
6ad51ab
to
a29e4d7
Compare
a29e4d7
to
4f67735
Compare
4f67735
to
f0b8f4a
Compare
f0b8f4a
to
0ad4b5e
Compare
0ad4b5e
to
e8dcd3a
Compare
e8dcd3a
to
c9c47e4
Compare
c9c47e4
to
c8d5ab2
Compare
c8d5ab2
to
8ffa46b
Compare
8ffa46b
to
e180760
Compare
e180760
to
596382a
Compare
596382a
to
b5eaa27
Compare
b5eaa27
to
3d93c47
Compare
3d93c47
to
715ac6b
Compare
d02102c
to
a832a74
Compare
a832a74
to
c16d91e
Compare
c16d91e
to
ec3e8a5
Compare
ec3e8a5
to
085d9b2
Compare
085d9b2
to
0760d0b
Compare
0760d0b
to
ebef97c
Compare
ebef97c
to
d9e5e4f
Compare
d9e5e4f
to
c39fb39
Compare
c39fb39
to
b5207c8
Compare
b5207c8
to
563f212
Compare
563f212
to
6a92a9a
Compare
6a92a9a
to
f03ae8b
Compare
f03ae8b
to
1ca205a
Compare
This PR contains the following updates:
0.15.5
->0.15.12
Release Notes
evanw/esbuild
v0.15.12
Compare Source
Fix minifier correctness bug with single-use substitutions (#2619)
When minification is enabled, esbuild will attempt to eliminate variables that are only used once in certain cases. For example, esbuild minifies this code:
into this code:
However, this transformation had a bug where esbuild did not correctly consider the "read" part of binary read-modify-write assignment operators. For example, it's incorrect to minify the following code into
bar += fn()
because the call tofn()
might modifybar
:In addition to fixing this correctness bug, this release also improves esbuild's output in the case where all values being skipped over are primitives:
Previous releases of esbuild didn't substitute these single-use variables here, but esbuild will now minify this to the following code starting with this release:
v0.15.11
Compare Source
Fix various edge cases regarding template tags and
this
(#2610)This release fixes some bugs where the value of
this
wasn't correctly preserved when evaluating template tags in a few edge cases. These edge cases are listed below:Each edge case in the code above previously incorrectly printed
false
when run through esbuild with--minify --target=es6
but now correctly printstrue
. These edge cases are unlikely to have affected real-world code.v0.15.10
Compare Source
Add support for node's "pattern trailers" syntax (#2569)
After esbuild implemented node's
exports
feature inpackage.json
, node changed the feature to also allow text after*
wildcards in patterns. Previously the*
was required to be at the end of the pattern. It lets you do something like this:With this release, esbuild now supports these types of patterns too.
Fix subpath imports with Yarn PnP (#2545)
Node has a little-used feature called subpath imports which are package-internal imports that start with
#
and that go through theimports
map inpackage.json
. Previously esbuild had a bug that caused esbuild to not handle these correctly in packages installed via Yarn's "Plug'n'Play" installation strategy. The problem was that subpath imports were being checked after Yarn PnP instead of before. This release reorders these checks, which should allow subpath imports to work in this case.Link from JS to CSS in the metafile (#1861, #2565)
When you import CSS into a bundled JS file, esbuild creates a parallel CSS bundle next to your JS bundle. So if
app.ts
imports some CSS files and you bundle it, esbuild will give youapp.js
andapp.css
. You would then add both<script src="app.js"></script>
and<link href="app.css" rel="stylesheet">
to your HTML to include everything in the page. This approach is more efficient than having esbuild insert additional JavaScript intoapp.js
that downloads and includesapp.css
because it means the browser can download and parse both the CSS and the JS in parallel (and potentially apply the CSS before the JS has even finished downloading).However, sometimes it's difficult to generate the
<link>
tag. One case is when you've added[hash]
to the entry names setting to include a content hash in the file name. Then the file name will look something likeapp-GX7G2SBE.css
and may change across subsequent builds. You can tell esbuild to generate build metadata using themetafile
API option but the metadata only tells you which generated JS bundle corresponds to a JS entry point (via theentryPoint
property), not which file corresponds to the associated CSS bundle. Working around this was hacky and involved string manipulation.This release adds the
cssBundle
property to the metafile to make this easier. It's present on the metadata for the generated JS bundle and points to the associated CSS bundle. So to generate the HTML tags for a given JS entry point, you first find the output file with theentryPoint
you are looking for (and put that in a<script>
tag), then check for thecssBundle
property to find the associated CSS bundle (and put that in a<link>
tag).One thing to note is that there is deliberately no
jsBundle
property mapping the other way because it's not a 1:1 relationship. Two JS bundles can share the same CSS bundle in the case where the associated CSS bundles have the same name and content. In that case there would be no one value for a hypotheticaljsBundle
property to have.v0.15.9
Compare Source
Fix an obscure npm package installation issue with
--omit=optional
(#2558)The previous release introduced a regression with
npm install esbuild --omit=optional
where the filenode_modules/.bin/esbuild
would no longer be present after installation. That could cause any package scripts which used theesbuild
command to no longer work. This release fixes the regression sonode_modules/.bin/esbuild
should now be present again after installation. This regression only affected people installing esbuild usingnpm
with either the--omit=optional
or--no-optional
flag, which is a somewhat unusual situation.More details:
The reason for this regression is due to some obscure npm implementation details. Since the Go compiler doesn't support trivial cross-compiling on certain Android platforms, esbuild's installer installs a WebAssembly shim on those platforms instead. In the previous release I attempted to simplify esbuild's WebAssembly shims to depend on the
esbuild-wasm
package instead of including another whole copy of the WebAssembly binary (to make publishing faster and to save on file system space after installation). However, both theesbuild
package and theesbuild-wasm
package provide a binary calledesbuild
and it turns out that addingesbuild-wasm
as a nested dependency of theesbuild
package (specificallyesbuild
optionally depends on@esbuild/android-arm
which depends onesbuild-wasm
) caused npm to be confused about whatnode_modules/.bin/esbuild
is supposed to be.It's pretty strange and unexpected that disabling the installation of optional dependencies altogether would suddenly cause an optional dependency's dependency to conflict with the top-level package. What happens under the hood is that if
--omit=optional
is present, npm attempts to uninstall theesbuild-wasm
nested dependency at the end ofnpm install
(even though theesbuild-wasm
package was never installed due to--omit=optional
). This uninstallation causesnode_modules/.bin/esbuild
to be deleted.After doing a full investigation, I discovered that npm's handling of the
.bin
directory is deliberately very brittle. When multiple packages in the dependency tree put something in.bin
with the same name, the end result is non-deterministic/random. What you get in.bin
might be from one package, from the other package, or might be missing entirely. The workaround suggested by npm is to just avoid having two packages that put something in.bin
with the same name. So this was fixed by making the@esbuild/android-arm
andesbuild-android-64
packages each include another whole copy of the WebAssembly binary, which works because these packages don't put anything in.bin
.v0.15.8
Compare Source
Fix JSX name collision edge case (#2534)
Code generated by esbuild could have a name collision in the following edge case:
automatic
, which causesimport
statements to be inserted{...spread}
followed by akey={...}
, which uses the legacycreateElement
fallback imported fromreact
react
such as@remix-run/react
import
statements are converted into require callsIn this case, esbuild previously generated two variables with the same name
import_react
, like this:That bug is fixed in this release. The code generated by esbuild no longer contains a name collision.
Fall back to WebAssembly on Android ARM (#1556, #1578, #2335, #2526)
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 ARM 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 ARM. So packages that depend on theesbuild
package should now work on Android ARM. This change has not yet been tested end-to-end because I don't have a 32-bit Android ARM device myself, but in theory it should work.This inherits the drawbacks of WebAssembly including significantly slower performance than native as well as potentially also more severe memory usage limitations and lack of certain features (e.g.
--serve
). If you want to use a native binary executable of esbuild on Android ARM, you may be able to build it yourself from source after installing the Android build tools.Attempt to better support Yarn's
ignorePatternData
feature (#2495)Part of resolving paths in a project using Yarn's Plug'n'Play feature involves evaluating a regular expression in the
ignorePatternData
property of.pnp.data.json
. However, it turns out that the particular regular expressions generated by Yarn use some syntax that works with JavaScript regular expressions but that does not work with Go regular expressions.In this release, esbuild will now strip some of the the problematic syntax from the regular expression before compiling it, which should hopefully allow it to be compiled by Go's regular expression engine. The specific character sequences that esbuild currently strips are as follows:
(?!\.)
(?!(?:^|\/)\.)
(?!\.{1,2}(?:\/|$))
(?!(?:^|\/)\.{1,2}(?:\/|$))
These seem to be used by Yarn to avoid the
.
and..
path segments in the middle of relative paths. The removal of these character sequences seems relatively harmless in this case since esbuild shouldn't ever generate such path segments. This change should add support to esbuild for Yarn'spnpIgnorePatterns
feature.Fix non-determinism issue with legacy block-level function declarations and strict mode (#2537)
When function declaration statements are nested inside a block in strict mode, they are supposed to only be available within that block's scope. But in "sloppy mode" (which is what non-strict mode is commonly called), they are supposed to be available within the whole function's scope:
To implement this, esbuild compiles these two functions differently to reflect their different semantics:
However, the compilation had a subtle bug where the automatically-generated function-level symbols for multible hoisted block-level function declarations in the same block a sloppy-mode context were generated in a random order if the output was in strict mode, which could be the case if TypeScript's
alwaysStrict
setting was set to true. This lead to non-determinism in the output as the minifier would randomly exchange the generated names for these symbols on different runs. This bug has been fixed by sorting the keys of the unordered map before iterating over them.Fix parsing of
@keyframes
with string identifiers (#2555)Firefox supports
@keyframes
with string identifier names. Previously this was treated as a syntax error by esbuild as it doesn't work in any other browser. The specification allows for this however, so it's technically not a syntax error (even though it would be unwise to use this feature at the moment). There was also a bug where esbuild would remove the identifier name in this case as the syntax wasn't recognized.This release changes esbuild's parsing of
@keyframes
to now consider this case to be an unrecognized CSS rule. That means it will be passed through unmodified (so you can now use esbuild to bundle this Firefox-specific CSS) but the CSS will not be pretty-printed or minified. I don't think it makes sense for esbuild to have special code to handle this Firefox-specific syntax at this time. This decision can be revisited in the future if other browsers add support for this feature.Add the
--jsx-side-effects
API option (#2539, #2546)By default esbuild assumes that JSX expressions are side-effect free, which means they are annoated with
/* @​__PURE__ */
comments and are removed during bundling when they are unused. This follows the common use of JSX for virtual DOM and applies to the vast majority of JSX libraries. However, some people have written JSX libraries that don't have this property. JSX expressions can have arbitrary side effects and can't be removed. If you are using such a library, you can now pass--jsx-side-effects
to tell esbuild that JSX expressions have side effects so it won't remove them when they are unused.This feature was contributed by @rtsao.
v0.15.7
Compare Source
Add
--watch=forever
to allow esbuild to never terminate (#1511, #1885)Currently using esbuild's watch mode via
--watch
from the CLI will stop watching if stdin is closed. The rationale is that stdin is automatically closed by the OS when the parent process exits, so stopping watch mode when stdin is closed ensures that esbuild's watch mode doesn't keep running forever after the parent process has been closed. For example, it would be bad if you wrote a shell script that didesbuild --watch &
to run esbuild's watch mode in the background, and every time you run the script it creates a newesbuild
process that runs forever.However, there are cases when it makes sense for esbuild's watch mode to never exit. One such case is within a short-lived VM where the lifetime of all processes inside the VM is expected to be the lifetime of the VM. Previously you could easily do this by piping the output of a long-lived command into esbuild's stdin such as
sleep 999999999 | esbuild --watch &
. However, this possibility often doesn't occur to people, and it also doesn't work on Windows. People also sometimes attempt to keep esbuild open by piping an infinite stream of data to esbuild such as withesbuild --watch </dev/zero &
which causes esbuild to spin at 100% CPU. So with this release, esbuild now has a--watch=forever
flag that will not stop watch mode when stdin is closed.Work around
PATH
withoutnode
in install script (#2519)Some people install esbuild's npm package in an environment without the
node
command in theirPATH
. This fails on Windows because esbuild's install script runs theesbuild
command before exiting as a sanity check, and on Windows theesbuild
command has to be a JavaScript file because of some internal details about how npm handles thebin
folder (specifically theesbuild
command lacks the.exe
extension, which is required on Windows). This release attempts to work around this problem by usingprocess.execPath
instead of"node"
as the command for running node. In theory this means the installer can now still function on Windows if something is wrong withPATH
.v0.15.6
Compare Source
Lower
for await
loops (#1930)This release lowers
for await
loops to the equivalentfor
loop containingawait
when esbuild is configured such thatfor await
loops are unsupported. This transform still requires at least generator functions to be supported since esbuild's lowering ofawait
currently relies on generators. This new transformation is mostly modeled after what the TypeScript compiler does. Here's an example:The code above will now become the following code with
--target=es2017
(omitting the code for the__forAwait
helper function):Automatically fix invalid
supported
configurations (#2497)The
--target=
setting lets you tell esbuild to target a specific version of one or more JavaScript runtimes such aschrome80,node14
and esbuild will restrict its output to only those features supported by all targeted JavaScript runtimes. More recently, esbuild introduced the--supported:
setting that lets you override which features are supported on a per-feature basis. However, this now lets you configure nonsensical things such as--supported:async-await=false --supported:async-generator=true
. Previously doing this could result in esbuild building successfully but producing invalid output.Starting with this release, esbuild will now attempt to automatically fix nonsensical feature override configurations by introducing more overrides until the configuration makes sense. So now the configuration from previous example will be changed such that
async-await=false
impliesasync-generator=false
. The full list of implications that were introduced is below:async-await=false
implies:async-generator=false
for-await=false
top-level-await=false
generator=false
implies:async-generator=false
object-accessors=false
implies:class-private-accessor=false
class-private-static-accessor=false
class-field=false
implies:class-private-field=false
class-static-field=false
implies:class-private-static-field=false
class=false
implies:class-field=false
class-private-accessor=false
class-private-brand-check=false
class-private-field=false
class-private-method=false
class-private-static-accessor=false
class-private-static-field=false
class-private-static-method=false
class-static-blocks=false
class-static-field=false
Implement a small minification improvement (#2496)
Some people write code that contains a label with an immediate break such as
x: break x
. Previously this code was not removed during minification but it will now be removed during minification starting with this release.Fix installing esbuild via Yarn with
enableScripts: false
configured (#2457)If esbuild is installed with Yarn with the
enableScripts: false
setting configured, then Yarn will not "unplug" theesbuild
package (i.e. it will keep the entire package inside a.zip
file). This messes with esbuild's library code that extracts the platform-specific binary executable because that code copies the binary executable into the esbuild package directory, and Yarn's.zip
file system shim doesn't let you write to a directory inside of a.zip
file. This release fixes this problem by writing to thenode_modules/.cache/esbuild
directory instead in this case. So you should now be able to use esbuild with Yarn whenenableScripts: false
is configured.This fix was contributed by @jonaskuske.
Configuration
📅 Schedule: Branch creation - "after 10pm every weekday,before 5am every weekday,every weekend" (UTC), Automerge - At any time (no schedule defined).
🚦 Automerge: Enabled.
♻ 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 Mend Renovate. View repository job log here.