Update dependency esbuild to v0.14.38

This PR contains the following updates:

Package	Change	Age	Adoption	Passing	Confidence
esbuild	`0.14.31` -> `0.14.38`

Release Notes

evanw/esbuild

### [`v0.14.38`](https://togithub.com/evanw/esbuild/blob/HEAD/CHANGELOG.md#01438) [Compare Source](https://togithub.com/evanw/esbuild/compare/v0.14.37...v0.14.38) - Further fixes to TypeScript 4.7 instantiation expression parsing ([#2201](https://togithub.com/evanw/esbuild/issues/2201)) This release fixes some additional edge cases with parsing instantiation expressions from the upcoming version 4.7 of TypeScript. Previously it was allowed for an instantiation expression to precede a binary operator but with this release, that's no longer allowed. This was sometimes valid in the TypeScript 4.7 beta but is no longer allowed in the latest version of TypeScript 4.7. Fixing this also fixed a regression that was introduced by the previous release of esbuild: | Code | TS 4.6.3 | TS 4.7.0 beta | TS 4.7.0 nightly | esbuild 0.14.36 | esbuild 0.14.37 | esbuild 0.14.38 | |----------------|--------------|---------------|------------------|-----------------|-----------------|-----------------| | `a == c` | Invalid | `a == c` | Invalid | `a == c` | `a == c` | Invalid | | `a in c` | Invalid | Invalid | Invalid | Invalid | `a in c` | Invalid | | `a>=c` | Invalid | Invalid | Invalid | Invalid | `a >= c` | Invalid | | `a=c` | Invalid | `a = c` | `a = c` | `a = c` | `a = c` | `a = c` | | `a>c` | `a > c` | `a > c` | `a > c` | `a > c` | `a > c` | `a > c` | This table illustrates some of the more significant changes between all of these parsers. The most important part is that esbuild 0.14.38 now matches the behavior of the latest TypeScript compiler for all of these cases. ### [`v0.14.37`](https://togithub.com/evanw/esbuild/blob/HEAD/CHANGELOG.md#01437) [Compare Source](https://togithub.com/evanw/esbuild/compare/v0.14.36...v0.14.37) - Add support for TypeScript's `moduleSuffixes` field from TypeScript 4.7 The upcoming version of TypeScript adds the `moduleSuffixes` field to `tsconfig.json` that introduces more rules to import path resolution. Setting `moduleSuffixes` to `[".ios", ".native", ""]` will try to look at the the relative files `./foo.ios.ts`, `./foo.native.ts`, and finally `./foo.ts` for an import path of `./foo`. Note that the empty string `""` in `moduleSuffixes` is necessary for TypeScript to also look-up `./foo.ts`. This was announced in the [TypeScript 4.7 beta blog post](https://devblogs.microsoft.com/typescript/announcing-typescript-4-7-beta/#resolution-customization-with-modulesuffixes). - Match the new ASI behavior from TypeScript nightly builds ([#2188](https://togithub.com/evanw/esbuild/pull/2188)) This release updates esbuild to match some very recent behavior changes in the TypeScript parser regarding automatic semicolon insertion. For more information, see TypeScript issues [#48711](https://togithub.com/evanw/esbuild/issues/48711) and [#48654](https://togithub.com/evanw/esbuild/issues/48654) (I'm not linking to them directly to avoid Dependabot linkback spam on these issues due to esbuild's popularity). The result is that the following TypeScript code is now considered valid TypeScript syntax: ```ts class A {} new A /* ASI now happens here */ if (0) {} interface B { (a: number): typeof a /* ASI now happens here */ (): void } ``` This fix was contributed by [@g-plane](https://togithub.com/g-plane). ### [`v0.14.36`](https://togithub.com/evanw/esbuild/blob/HEAD/CHANGELOG.md#01436) [Compare Source](https://togithub.com/evanw/esbuild/compare/v0.14.35...v0.14.36) - Revert path metadata validation for now ([#2177](https://togithub.com/evanw/esbuild/issues/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`](https://togithub.com/evanw/esbuild/blob/HEAD/CHANGELOG.md#01435) [Compare Source](https://togithub.com/evanw/esbuild/compare/v0.14.34...v0.14.35) - Add support for parsing `typeof` on #private fields from TypeScript 4.7 ([#2174](https://togithub.com/evanw/esbuild/pull/2174)) The upcoming version of TypeScript now lets you use `#private` fields in `typeof` type expressions: https://devblogs.microsoft.com/typescript/announcing-typescript-4-7-beta/#typeof-on-private-fields ```ts class Container { #data = "hello!"; get data(): typeof this.#data { return this.#data; } set data(value: typeof this.#data) { this.#data = value; } } ``` With this release, esbuild can now parse these new type expressions as well. This feature was contributed by [@magic-akari](https://togithub.com/magic-akari). - Add Opera and IE to internal CSS feature support matrix ([#2170](https://togithub.com/evanw/esbuild/pull/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: ```css /* Original input */ a { color: rgba(0, 0, 0, 0.5); } /* Old output (with --target=opera49 --minify) */ a{color:rgba(0,0,0,.5)} /* New output (with --target=opera49 --minify) */ a{color:#00000080} ``` The fix for this issue was contributed by [@sapphi-red](https://togithub.com/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 in `tsconfig.json` is set to `ESNext`. Specifically, the default value for TypeScript's `useDefineForClassFields` setting when unspecified is `true` if and only if `target` is `ESNext`. TypeScript 4.6 introduced another change where this behavior now happens for both `ESNext` and `ES2022`. Presumably this will be the case for `ES2023` 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 inconsistent `sideEffects` metadata: ```js let buggyPlugin = { name: 'buggy', setup(build) { let count = 0 build.onResolve({ filter: /^react$/ }, args => { return { path: require.resolve(args.path), sideEffects: count++ > 0, } }) }, } ``` 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: ✘ [ERROR] [plugin buggy] Detected inconsistent metadata for the path "node_modules/react/index.js" when it was imported here: button.tsx:1:30: 1 │ import { createElement } from 'react' ╵ ~~~~~~~ The original metadata for that path comes from when it was imported here: app.tsx:1:23: 1 │ import * as React from 'react' ╵ ~~~~~~~ The difference in metadata is displayed below: { - "sideEffects": true, + "sideEffects": false, } This is a bug in the "buggy" plugin. Plugins provide metadata for a given path in an "onResolve" callback. All metadata provided for the same path must be consistent to ensure deterministic builds. Due to parallelism, one set of provided metadata will be randomly chosen for a given path, so providing inconsistent metadata for the same path can cause non-determinism. - Suggest enabling a missing condition when `exports` map fails ([#2163](https://togithub.com/evanw/esbuild/issues/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): ✘ [ERROR] Could not resolve "@sentry/electron/main" index.js:1:24: 1 │ import * as Sentry from '@sentry/electron/main' ╵ ~~~~~~~~~~~~~~~~~~~~~~~ The path "./main" is not currently exported by package "@sentry/electron": node_modules/@sentry/electron/package.json:8:13: 8 │ "exports": { ╵ ^ None of the conditions provided ("require", "module") match any of the currently active conditions ("browser", "default", "import"): node_modules/@sentry/electron/package.json:16:14: 16 │ "./main": { ╵ ^ Consider enabling the "module" condition if this package expects it to be enabled. You can use "--conditions=module" to do that: node_modules/@sentry/electron/package.json:18:6: 18 │ "module": "./esm/main/index.js" ╵ ~~~~~~~~ Consider using a "require()" call to import this file, which will work because the "require" condition is supported by this package: index.js:1:24: 1 │ import * as Sentry from '@sentry/electron/main' ╵ ~~~~~~~~~~~~~~~~~~~~~~~ You can mark the path "@sentry/electron/main" as external to exclude it from the bundle, which will remove this error. This particular package had an issue where it was using the Webpack-specific `module` condition without providing a `default` condition. It looks like the intent in this case was to use the standard `import` condition instead. This specific change wasn't suggested here because this error message is for package consumers, not package authors. ### [`v0.14.34`](https://togithub.com/evanw/esbuild/blob/HEAD/CHANGELOG.md#01434) [Compare Source](https://togithub.com/evanw/esbuild/compare/v0.14.33...v0.14.34) Something went wrong with the publishing script for the previous release. Publishing again. ### [`v0.14.33`](https://togithub.com/evanw/esbuild/blob/HEAD/CHANGELOG.md#01433) [Compare Source](https://togithub.com/evanw/esbuild/compare/v0.14.32...v0.14.33) - Fix a regression regarding `super` ([#2158](https://togithub.com/evanw/esbuild/issues/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 to `super()`, which is invalid. This problem has now been fixed (notice that `this` is now used after `super()` instead of before): ```js // Original code class Foo extends Object { static FOO; constructor() { super(); } #foo; } // Old output (with --bundle) var _foo; var Foo = class extends Object { constructor() { __privateAdd(this, _foo, void 0); super(); } }; _foo = new WeakMap(); __publicField(Foo, "FOO"); // New output (with --bundle) var _foo; var Foo = class extends Object { constructor() { super(); __privateAdd(this, _foo, void 0); } }; _foo = new WeakMap(); __publicField(Foo, "FOO"); ``` 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 new `super()` 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) adjusting `super()` 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: ```js class Foo { get #foo() {} static bar = new Foo().#foo } ``` We can't just lower static fields without also lowering private members, since that causes a syntax error: ```js class Foo { get #foo() {} } Foo.bar = new Foo().#foo; ``` And the reason lowering private members requires adjusting `super()` calls is because the injected private member initializers use `this`, which is only accessible after `super()` calls in the constructor. - Fix an issue with `--keep-names` not keeping some names ([#2149](https://togithub.com/evanw/esbuild/issues/2149)) This release fixes a regression with `--keep-names` from version 0.14.26. PR [#2062](https://togithub.com/evanw/esbuild/pull/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: ```js class Foo { static get #foo() { return Foo.name } static get foo() { return this.#foo } } let Bar = Foo Foo = { name: 'Bar' } console.log(Foo.name, Bar.name) ``` 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): ```js var _foo, foo_get; const _Foo = class { static get foo() { return __privateGet(this, _foo, foo_get); } }; let Foo = _Foo; __name(Foo, "Foo"); _foo = new WeakSet(); foo_get = /* @__PURE__ */ __name(function() { return _Foo.name; }, "#foo"); __privateAdd(Foo, _foo); let Bar = Foo; Foo = { name: "Bar" }; console.log(Foo.name, Bar.name); ``` The injection of the automatically-generated `_Foo` variable is necessary to preserve the semantics of the captured `Foo` 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 if `Foo` 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](https://togithub.com/evanw/esbuild/issues/2162)) When `--minify` is active, esbuild will now use one fewer byte to represent certain large integers: ```js // Original code x = 123456787654321; // Old output (with --minify) x=123456787654321; // New output (with --minify) x=0x704885f926b1; ``` This works because a hexadecimal representation can be shorter than a decimal representation starting at around 10¹² 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 than `4294967295` 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](https://togithub.com/evanw/esbuild/issues/2156)) This release adds Linux ARM64 support to esbuild's [Deno](https://deno.land/) API implementation, which allows esbuild to be used with Deno on a Raspberry Pi. ### [`v0.14.32`](https://togithub.com/evanw/esbuild/blob/HEAD/CHANGELOG.md#01432) [Compare Source](https://togithub.com/evanw/esbuild/compare/v0.14.31...v0.14.32) - Fix `super` usage in lowered private methods ([#2039](https://togithub.com/evanw/esbuild/issues/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 the `super` 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: ```js // Original code class Derived extends Base { #foo() { super.foo() } bar() { this.#foo() } } // Old output (with --target=es6) var _foo, foo_fn; class Derived extends Base { constructor() { super(...arguments); __privateAdd(this, _foo); } bar() { __privateMethod(this, _foo, foo_fn).call(this); } } _foo = new WeakSet(); foo_fn = function() { super.foo(); }; // New output (with --target=es6) var _foo, foo_fn; const _Derived = class extends Base { constructor() { super(...arguments); __privateAdd(this, _foo); } bar() { __privateMethod(this, _foo, foo_fn).call(this); } }; let Derived = _Derived; _foo = new WeakSet(); foo_fn = function() { __superGet(_Derived.prototype, this, "foo").call(this); }; ``` 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 all `super` property accesses on instances including those inside lowered `async` functions. The new approach is different but should be equivalent to the old approach: ```js // Original code class Foo { foo = async () => super.foo() } // Old output (with --target=es6) class Foo { constructor() { __publicField(this, "foo", () => { var __superGet = (key) => super[key]; return __async(this, null, function* () { return __superGet("foo").call(this); }); }); } } // New output (with --target=es6) class Foo { constructor() { __publicField(this, "foo", () => __async(this, null, function* () { return __superGet(Foo.prototype, this, "foo").call(this); })); } } ``` - 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: ```js // Original code let shouldRemove = { [1]: 2 } let shouldRemove2 = class { #foo } let shouldKeep = class { [{ toString() { sideEffect() } }] } // Old output (with --tree-shaking=true) let shouldRemove = { [1]: 2 }; let shouldRemove2 = class { #foo; }; // New output (with --tree-shaking=true) let shouldKeep = class { [{ toString() { sideEffect(); } }]; }; ``` - Add the `wasmModule` option to the `initialize` JS API ([#1093](https://togithub.com/evanw/esbuild/issues/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 the `wasmURL` API option like this: ```js await esbuild.initialize({ wasmURL: '/node_modules/esbuild-wasm/esbuild.wasm', }) console.log(await esbuild.transform('1+2')) ``` With this release, you can now also initialize esbuild using a `WebAssembly.Module` instance using the `wasmModule` API option instead. The example above is equivalent to the following code: ```js await esbuild.initialize({ wasmModule: await WebAssembly.compileStreaming(fetch('/node_modules/esbuild-wasm/esbuild.wasm')) }) console.log(await esbuild.transform('1+2')) ``` 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.

Configuration

📅 Schedule: "before 3am on the first day of the month" (UTC).

🚦 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.

[ ] If you want to rebase/retry this PR, click this checkbox.

This PR has been generated by WhiteSource Renovate. View repository job log here.

DaveKeehl / svelte-reveal

Update dependency esbuild to v0.14.38 #131

Release Notes

Configuration

Codecov Report