fix(deps): update dependency esbuild to v0.11.8

This PR contains the following updates:

Package	Change	Age	Adoption	Passing	Confidence
esbuild	`0.11.5` -> `0.11.8`

Release Notes

evanw/esbuild

### [`v0.11.8`](https://togithub.com/evanw/esbuild/blob/master/CHANGELOG.md#0118) [Compare Source](https://togithub.com/evanw/esbuild/compare/v0.11.7...v0.11.8) - Fix hash calculation for code splitting and dynamic imports ([#1076](https://togithub.com/evanw/esbuild/issues/1076)) The hash included in the file name of each output file is intended to change if and only if anything relevant to the content of that output file changes. It includes: - The contents of the file with the paths of other output files omitted - The output path of the file the final hash omitted - Some information about the input files involved in that output file - The contents of the associated source map, if there is one - All of the information above for all transitive dependencies found by following `import` statements However, this didn't include dynamic `import()` expressions due to an oversight. With this release, dynamic `import()` expressions are now also counted as transitive dependencies. This fixes an issue where the content of an output file could change without its hash also changing. As a side effect of this change, dynamic imports inside output files of other output files are now listed in the metadata file if the `metafile` setting is enabled. - Refactor the internal module graph representation This release changes a large amount of code relating to esbuild's internal module graph. The changes are mostly organizational and help consolidate most of the logic around maintaining various module graph invariants into a separate file where it's easier to audit. The Go language doesn't have great abstraction capabilities (e.g. no zero-cost iterators) so the enforcement of this new abstraction is unfortunately done by convention instead of by the compiler, and there is currently still some code that bypasses the abstraction. But it's better than it was before. Another relevant change was moving a number of special cases that happened during the tree shaking traversal into the graph itself instead. Previously there were quite a few implicit dependency rules that were checked in specific places, which was hard to follow. Encoding these special case constraints into the graph itself makes the problem easier to reason about and should hopefully make the code more regular and robust. Finally, this set of changes brings back full support for the `sideEffects` annotation in `package.json`. It was previously disabled when code splitting was active as a temporary measure due to the discovery of some bugs in that scenario. But I believe these bugs have been resolved now that tree shaking and code splitting are done in separate passes (see the previous release for more information). ### [`v0.11.7`](https://togithub.com/evanw/esbuild/blob/master/CHANGELOG.md#0117) [Compare Source](https://togithub.com/evanw/esbuild/compare/v0.11.6...v0.11.7) - Fix incorrect chunk reference with code splitting, css, and dynamic imports ([#1125](https://togithub.com/evanw/esbuild/issues/1125)) This release fixes a bug where when you use code splitting, CSS imports in JS, and dynamic imports all combined, the dynamic import incorrectly references the sibling CSS chunk for the dynamic import instead of the primary JS chunk. In this scenario the entry point file corresponds to two different output chunks (one for CSS and one for JS) and the wrong chunk was being picked. This bug has been fixed. - Split apart tree shaking and code splitting ([#1123](https://togithub.com/evanw/esbuild/issues/1123)) The original code splitting algorithm allowed for files to be split apart and for different parts of the same file to end up in different chunks based on which entry points needed which parts. This was done at the same time as tree shaking by essentially performing tree shaking multiple times, once per entry point, and tracking which entry points each file part is live in. Each file part that is live in at least one entry point was then assigned to a code splitting chunk with all of the other code that is live in the same set of entry points. This ensures that entry points only import code that they will use (i.e. no code will be downloaded by an entry point that is guaranteed to not be used). This file-splitting feature has been removed because it doesn't work well with the recently-added top-level await JavaScript syntax, which has complex evaluation order rules that operate at file boundaries. File parts now have a single boolean flag for whether they are live or not instead of a set of flags that track which entry points that part is reachable from (reachability is still tracked at the file level). However, this change appears to have introduced some subtly incorrect behavior with code splitting because there is now an implicit dependency in the import graph between adjacent parts within the same file even if the two parts are unrelated and don't reference each other. This is due to the fact each entry point that references one part pulls in the file (but not the whole file, only the parts that are live in at least one entry point). So liveness must be fully computed first before code splitting is computed. This release splits apart tree shaking and code splitting into two separate passes, which fixes certain cases where two generated code splitting chunks ended up each importing symbols from the other and causing a cycle. There should hopefully no longer be cycles in generated code splitting chunks. - Make `this` work in static class fields in TypeScript files Currently `this` is mis-compiled in static fields in TypeScript files if the `useDefineForClassFields` setting in `tsconfig.json` is `false` (the default value): ```js class Foo { static foo = 123 static bar = this.foo } console.log(Foo.bar) ``` This is currently compiled into the code below, which is incorrect because it changes the value of `this` (it's supposed to refer to `Foo`): ```js class Foo { } Foo.foo = 123; Foo.bar = this.foo; console.log(Foo.bar); ``` This was an intentionally unhandled case because the TypeScript compiler doesn't handle this either (esbuild's currently incorrect output matches the output from the TypeScript compiler, which is also currently incorrect). However, the TypeScript compiler might fix their output at some point in which case esbuild's behavior would become problematic. So this release now generates the correct output: ```js const _Foo = class { }; let Foo = _Foo; Foo.foo = 123; Foo.bar = _Foo.foo; console.log(Foo.bar); ``` Presumably the TypeScript compiler will be fixed to also generate something like this in the future. If you're wondering why esbuild generates the extra `_Foo` variable, it's defensive code to handle the possibility of the class being reassigned, since class declarations are not constants: ```js class Foo { static foo = 123 static bar = () => Foo.foo } let bar = Foo.bar Foo = { foo: 321 } console.log(bar()) ``` We can't just move the initializer containing `Foo.foo` outside of the class body because in JavaScript, the class name is shadowed inside the class body by a special hidden constant that is equal to the class object. Even if the class is reassigned later, references to that shadowing symbol within the class body should still refer to the original class object. - Various fixes for private class members ([#1131](https://togithub.com/evanw/esbuild/issues/1131)) This release fixes multiple issues with esbuild's handling of the `#private` syntax. Previously there could be scenarios where references to `this.#private` could be moved outside of the class body, which would cause them to become invalid (since the `#private` name is only available within the class body). One such case is when TypeScript's `useDefineForClassFields` setting has the value `false` (which is the default value), which causes class field initializers to be replaced with assignment expressions to avoid using "define" semantics: ```js class Foo { static #foo = 123 static bar = Foo.#foo } ``` Previously this was turned into the following code, which is incorrect because `Foo.#foo` was moved outside of the class body: ```js class Foo { static #foo = 123; } Foo.bar = Foo.#foo; ``` This is now handled by converting the private field syntax into normal JavaScript that emulates it with a `WeakMap` instead. This conversion is fairly conservative to make sure certain edge cases are covered, so this release may unfortunately convert more private fields than previous releases, even when the target is `esnext`. It should be possible to improve this transformation in future releases so that this happens less often while still preserving correctness. ### [`v0.11.6`](https://togithub.com/evanw/esbuild/blob/master/CHANGELOG.md#0116) [Compare Source](https://togithub.com/evanw/esbuild/compare/v0.11.5...v0.11.6) - Fix an incorrect minification transformation ([#1121](https://togithub.com/evanw/esbuild/issues/1121)) This release removes an incorrect substitution rule in esbuild's peephole optimizer, which is run when minification is enabled. The incorrect rule transformed `if(a && falsy)` into `if(a, falsy)` which is equivalent if `falsy` has no side effects (such as the literal `false`). However, the rule didn't check that the expression is side-effect free first which could result in miscompiled code. I have removed the rule instead of modifying it to check for the lack of side effects first because while the code is slightly smaller, it may also be more expensive at run-time which is undesirable. The size savings are also very insignificant. - Change how `NODE_PATH` works to match node ([#1117](https://togithub.com/evanw/esbuild/issues/1117)) Node searches for packages in nearby `node_modules` directories, but it also allows you to inject extra directories to search for packages in using the `NODE_PATH` environment variable. This is supported when using esbuild's CLI as well as via the `nodePaths` option when using esbuild's API. Node's module resolution algorithm is well-documented, and esbuild's path resolution is designed to follow it. The full algorithm is here: . However, it appears that the documented algorithm is incorrect with regard to `NODE_PATH`. The documentation says `NODE_PATH` directories should take precedence over `node_modules` directories, and so that's how esbuild worked. However, in practice node actually does it the other way around. Starting with this release, esbuild will now allow `node_modules` directories to take precedence over `NODE_PATH` directories. This is a deviation from the published algorithm. - Provide a better error message for incorrectly-quoted JSX attributes ([#959](https://togithub.com/evanw/esbuild/issues/959), [#1115](https://togithub.com/evanw/esbuild/issues/1115)) People sometimes try to use the output of `JSON.stringify()` as a JSX attribute when automatically-generating JSX code. Doing so is incorrect because JSX strings work like XML instead of like JS (since JSX is XML-in-JS). Specifically, using a backslash before a quote does not cause it to be escaped: ```jsx // JSX ends the "content" attribute here and sets "content" to 'some so-called \\' // v let button =

Configuration

:date: Schedule: "after 9pm on sunday" (UTC).

:vertical_traffic_light: Automerge: Enabled.

:recycle: Rebasing: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox.

:no_bell: Ignore: Close this PR and you won't be reminded about this update again.

[ ] If you want to rebase/retry this PR, check this box.

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

NullVoxPopuli / emberclear

fix(deps): update dependency esbuild to v0.11.8 #1574

Release Notes

Configuration