Update dependency esbuild to v0.9.2

This PR contains the following updates:

Package	Change	Age	Adoption	Passing	Confidence
esbuild	`0.9.0` -> `0.9.2`

Release Notes

evanw/esbuild

### [`v0.9.2`](https://togithub.com/evanw/esbuild/blob/master/CHANGELOG.md#092) [Compare Source](https://togithub.com/evanw/esbuild/compare/v0.9.1...v0.9.2) - Fix export name annotations in CommonJS output for node ([#960](https://togithub.com/evanw/esbuild/issues/960)) The previous release introduced a regression that caused a syntax error when building ESM files that have a default export with `--platform=node`. This is because the generated export contained the `default` keyword like this: `0 && (module.exports = {default});`. This regression has been fixed. ### [`v0.9.1`](https://togithub.com/evanw/esbuild/blob/master/CHANGELOG.md#091) [Compare Source](https://togithub.com/evanw/esbuild/compare/v0.9.0...v0.9.1) - Fix bundling when parent directory is inaccessible ([#938](https://togithub.com/evanw/esbuild/issues/938)) Previously bundling with esbuild when a parent directory is inaccessible did not work because esbuild would try to read the directory to search for a `node_modules` folder and would then fail the build when that failed. In practice this caused issues in certain Linux environments where a directory close to the root directory was inaccessible (e.g. on Android). With this release, esbuild will treat inaccessible directories as empty to allow for the `node_modules` search to continue past the inaccessible directory and into its parent directory. This means it should now be possible to bundle with esbuild in these situations. - Avoid allocations in JavaScript API stdout processing ([#941](https://togithub.com/evanw/esbuild/pull/941)) This release improves the efficiency of the JavaScript API. The API runs the binary esbuild executable in a child process and then communicates with it over stdin/stdout. Previously the stdout buffer containing the remaining partial message was copied after each batch of messages due to a bug. This was unintentional and unnecessary, and has been removed. Now this part of the code no longer involves any allocations. This fix was contributed by [@jridgewell](https://togithub.com/jridgewell). - Support conditional `@import` syntax when not bundling ([#953](https://togithub.com/evanw/esbuild/issues/953)) Previously conditional CSS imports such as `@import "print.css" print;` was not supported at all and was considered a syntax error. With this release, it is now supported in all cases except when bundling an internal import. Support for bundling internal CSS imports is planned but will happen in a later release. - Always lower object spread and rest when targeting V8 ([#951](https://togithub.com/evanw/esbuild/issues/951)) This release causes object spread (e.g. `a = {...b}`) and object rest (e.g. `{...a} = b`) to always be lowered to a manual implementation instead of using native syntax when the `--target=` parameter includes a V8-based JavaScript runtime such as `chrome`, `edge`, or `node`. It turns out this feature is implemented inefficiently in V8 and copying properties over to a new object is around a 2x performance improvement. In addition, doing this manually instead of using the native implementation generates a lot less work for the garbage collector. You can see [V8 bug 11536](https://bugs.chromium.org/p/v8/issues/detail?id=11536) for details. If the V8 performance bug is eventually fixed, the translation of this syntax will be disabled again for V8-based targets containing the bug fix. - Fix object rest return value ([#956](https://togithub.com/evanw/esbuild/issues/956)) This release fixes a bug where the value of an object rest assignment was incorrect if the object rest assignment was lowered: ```js // This code was affected let x, y console.log({x, ...y} = {x: 1, y: 2}) ``` Previously this code would incorrectly print `{y: 2}` (the value assigned to `y`) when the object rest expression was lowered (i.e. with `--target=es2017` or below). Now this code will correctly print `{x: 1, y: 2}` instead. This bug did not affect code that did not rely on the return value of the assignment expression, such as this code: ```js // This code was not affected let x, y ({x, ...y} = {x: 1, y: 2}) ``` - Basic support for CSS page margin rules ([#955](https://togithub.com/evanw/esbuild/issues/955)) There are 16 different special at-rules that can be nested inside the `@page` rule. They are defined in [this specification](https://www.w3.org/TR/css-page-3/#syntax-page-selector). Previously esbuild treated these as unknown rules, but with this release esbuild will now treat these as known rules. The only real difference in behavior is that esbuild will no longer warn about these rules being unknown. - Add export name annotations to CommonJS output for node When you import a CommonJS file using an ESM `import` statement in node, the `default` import is the value of `module.exports` in the CommonJS file. In addition, node attempts to generate named exports for properties of the `module.exports` object. Except that node doesn't actually ever look at the properties of that object to determine the export names. Instead it parses the CommonJS file and scans the AST for certain syntax patterns. A full list of supported patterns can be found in the [documentation for the `cjs-module-lexer` package](https://togithub.com/guybedford/cjs-module-lexer#grammar). This library doesn't currently support the syntax patterns used by esbuild. While esbuild could adapt its syntax to these patterns, the patterns are less compact than the ones used by esbuild and doing this would lead to code bloat. Supporting two separate ways of generating export getters would also complicate esbuild's internal implementation, which is undesirable. Another alternative could be to update the implementation of `cjs-module-lexer` to support the specific patterns used by esbuild. This is also undesirable because this pattern detection would break when minification is enabled, this would tightly couple esbuild's output format with node and prevent esbuild from changing it, and it wouldn't work for existing and previous versions of node that still have the old version of this library. Instead, esbuild will now add additional code to "annotate" ESM files that have been converted to CommonJS when esbuild's platform has been set to `node`. The annotation is dead code but is still detected by the `cjs-module-lexer` library. If the original ESM file has the exports `foo` and `bar`, the additional annotation code will look like this: ```js 0 && (module.exports = {foo, bar}); ``` This allows you to use named imports with an ESM `import` statement in node (previously you could only use the `default` import): ```js import { foo, bar } from './file-built-by-esbuild.cjs' ```

Renovate configuration

:date: Schedule: At any time (no schedule defined).

:vertical_traffic_light: Automerge: Disabled by config. Please merge this manually once you are satisfied.

:recycle: Rebasing: Renovate will not automatically rebase this PR, because other commits have been found.

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

gagoar / use-herald-action

Update dependency esbuild to v0.9.2 #397

Release Notes

Renovate configuration

Codecov Report