-
Expose build options to plugins (#373)
Plugins can now access build options from within the plugin using the
initialOptions
property. For example:let nodeEnvPlugin = { name: 'node-env', setup(build) { const options = build.initialOptions options.define = options.define || {} options.define['process.env.NODE_ENV'] = options.minify ? '"production"' : '"development"' }, }
-
Fix an edge case with the object spread transform (#1017)
This release fixes esbuild's object spread transform in cases where property assignment could be different than property definition. For example:
console.log({ get x() {}, ...{x: 1}, })
This should print
{x: 1}
but transforming this through esbuild with--target=es6
causes the resulting code to throw an error. The problem is that esbuild currently transforms this code to a call toObject.assign
and that uses property assignment semantics, which causes the assignment to throw (since you can't assign to a getter-only property).With this release, esbuild will now transform this into code that manually loops over the properties and copies them over one-by-one using
Object.defineProperty
instead. This uses property definition semantics which better matches the specification. -
Fix a TypeScript parsing edge case with arrow function return types (#1016)
This release fixes the following TypeScript parsing edge case:
():Array<number>=>{return [1]}
This was tripping up esbuild's TypeScript parser because the
>=
token was split into a>
token and a=
token because the>
token is needed to close the type parameter list, but the=
token was not being combined with the following>
token to form a=>
token. This is normally not an issue because there is normally a space in between the>
and the=>
tokens here. The issue only happened when the spaces were removed. This bug has been fixed. Now after the>=
token is split, esbuild will expand the=
token into the following characters if possible, which can result in a=>
,==
, or===
token. -
Enable faster synchronous transforms under a flag (#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.There was previously a workaround for this limitation that uses node's
worker_threads
API and atomics to block the main thread while asynchronous communication happens in a worker, but that was reverted due to a bug in node'sworker_threads
implementation. Now that this bug has been fixed by node, I am re-enabling this workaround. This should result intransformSync
andbuildSync
being much faster.This approach is experimental and is currently only enabled if the
ESBUILD_WORKER_THREADS
environment variable is present. If this use case matters to you, please try it out and let me know if you find any problems with it. -
Update how optional chains are compiled to match new V8 versions (#1019)
An optional chain is an expression that uses the
?.
operator, which roughly avoids evaluation of the right-hand side if the left-hand side isnull
orundefined
. Soa?.b
is basically equivalent toa == null ? void 0 : a.b
. When the language target is set toes2019
or below, esbuild will transform optional chain expressions into equivalent expressions that do not use the?.
operator.This transform is designed to match the behavior of V8 exactly, and is designed to do something similar to the equivalent transform done by the TypeScript compiler. However, V8 has recently changed its behavior in two cases:
-
Forced call of an optional member expression should propagate the object to the method:
const o = { m() { return this; } }; assert((o?.m)() === o);
V8 bug: https://bugs.chromium.org/p/v8/issues/detail?id=10024
-
Optional call of
eval
must be an indirect eval:globalThis.a = 'global'; var b = (a => eval?.('a'))('local'); assert(b === 'global');
V8 bug: https://bugs.chromium.org/p/v8/issues/detail?id=10630
This release changes esbuild's transform to match V8's new behavior. The transform in the TypeScript compiler is still emulating the old behavior as of version 4.2.3, so these syntax forms should be avoided in TypeScript code for portability.
-