Update dependency esbuild to v0.12.26

This PR contains the following updates:

Package	Change	Age	Adoption	Passing	Confidence
esbuild	`0.12.22` -> `0.12.26`

Release Notes

evanw/esbuild

### [`v0.12.26`](https://togithub.com/evanw/esbuild/blob/master/CHANGELOG.md#01226) [Compare Source](https://togithub.com/evanw/esbuild/compare/v0.12.25...v0.12.26) - Add `--analyze` to print information about the bundle ([#1568](https://togithub.com/evanw/esbuild/issues/1568)) The `--metafile=` flag tells esbuild to write information about the bundle into the provided metadata file in JSON format. It contains information about the input files and which other files each one imports, as well as the output files and which input files they include. This information is sufficient to answer many questions such as: - Which files are in my bundle? - What's are the biggest files in my bundle? - Why is this file included in my bundle? Previously you had to either write your own code to answer these questions, or use another tool such as https://bundle-buddy.com/esbuild to visualize the data. Starting with this release you can now also use `--analyze` to enable esbuild's built-in visualizer. It looks like this: $ esbuild --bundle example.jsx --outfile=out.js --minify --analyze out.js 27.6kb ⚡ Done in 6ms out.js 27.6kb 100.0% ├ node_modules/react-dom/cjs/react-dom-server.browser.production.min.js 19.2kb 69.8% ├ node_modules/react/cjs/react.production.min.js 5.9kb 21.4% ├ node_modules/object-assign/index.js 965b 3.4% ├ example.jsx 137b 0.5% ├ node_modules/react-dom/server.browser.js 50b 0.2% └ node_modules/react/index.js 50b 0.2% This tells you what input files were bundled into each output file as well as the final minified size contribution of each input file as well as the percentage of the output file it takes up. You can also enable verbose analysis with `--analyze=verbose` to see why each input file was included (i.e. which files imported it from the entry point file): $ esbuild --bundle example.jsx --outfile=out.js --minify --analyze=verbose out.js 27.6kb ⚡ Done in 6ms out.js ─────────────────────────────────────────────────────────────────── 27.6kb ─ 100.0% ├ node_modules/react-dom/cjs/react-dom-server.browser.production.min.js ─ 19.2kb ── 69.8% │ └ node_modules/react-dom/server.browser.js │ └ example.jsx ├ node_modules/react/cjs/react.production.min.js ───────────────────────── 5.9kb ── 21.4% │ └ node_modules/react/index.js │ └ example.jsx ├ node_modules/object-assign/index.js ──────────────────────────────────── 965b ──── 3.4% │ └ node_modules/react-dom/cjs/react-dom-server.browser.production.min.js │ └ node_modules/react-dom/server.browser.js │ └ example.jsx ├ example.jsx ──────────────────────────────────────────────────────────── 137b ──── 0.5% ├ node_modules/react-dom/server.browser.js ──────────────────────────────── 50b ──── 0.2% │ └ example.jsx └ node_modules/react/index.js ───────────────────────────────────────────── 50b ──── 0.2% └ example.jsx There is also a JS API for this: ```js const result = await esbuild.build({ metafile: true, ... }) console.log(await esbuild.analyzeMetafile(result.metafile, { verbose: true, })) ``` and a Go API: ```js result := api.Build(api.BuildOptions{ Metafile: true, ... }) fmt.Println(api.AnalyzeMetafile(result.Metafile, api.AnalyzeMetafileOptions{ Verbose: true, })) ``` Note that this is not the only way to visualize this data. If you want a visualization that's different than the information displayed here, you can easily build it yourself using the information in the metafile that is generated with the `--metafile=` flag. Also note that this data is intended for humans, not machines. The specific format of this data may change over time which will likely break any tools that try to parse it. You should not write a tool to parse this data. You should be using the information in the JSON metadata file instead. Everything in this visualization is derived from the JSON metadata so you are not losing out on any information by not using esbuild's output. - Allow `require.resolve` in non-node builds ([#1579](https://togithub.com/evanw/esbuild/issues/1579)) With this release, you can now use `require.resolve` in builds when the target platform is set to `browser` instead of `node` as long as the function `window.require.resolve` exists somehow. This was already possible when the platform is `node` but when the platform is `browser`, esbuild generates a no-op shim `require` function for compatibility reasons (e.g. because some code expects `typeof require` must be `"function"` even in the browser). The shim previously had a fallback to `window.require` if it exists, but additional properties of the `require` function such as `require.resolve` were not copied over to the shim. Now the shim function is only used if `window.require` is undefined so additional properties such as `require.resolve` should now work. This change was contributed by [@screetBloom](https://togithub.com/screetBloom). ### [`v0.12.25`](https://togithub.com/evanw/esbuild/blob/master/CHANGELOG.md#01225) [Compare Source](https://togithub.com/evanw/esbuild/compare/v0.12.24...v0.12.25) - Fix a TypeScript parsing edge case with the postfix `!` operator ([#1560](https://togithub.com/evanw/esbuild/issues/1560)) This release fixes a bug with esbuild's TypeScript parser where the postfix `!` operator incorrectly terminated a member expression after the `new` operator: ```js // Original input new Foo!.Bar(); // Old output new Foo().Bar(); // New output new Foo.Bar(); ``` The problem was that `!` was considered a postfix operator instead of part of a member expression. It is now considered to be part of a member expression instead, which fixes this edge case. - Fix a parsing crash with nested private brand checks This release fixes a bug in the parser where code of the form `#a in #b in c` caused a crash. This code now causes a syntax error instead. Private identifiers are allowed when followed by `in`, but only if the operator precedence level is such that the `in` operator is allowed. The parser was missing the operator precedence check. - Publish x86-64 binary executables for illumos ([#1562](https://togithub.com/evanw/esbuild/pull/1562)) This release adds support for the [illumos](https://www.illumos.org/) operating system, which is related to Solaris and SunOS. Support for this platform was contributed by [@hadfl](https://togithub.com/hadfl). ### [`v0.12.24`](https://togithub.com/evanw/esbuild/blob/master/CHANGELOG.md#01224) [Compare Source](https://togithub.com/evanw/esbuild/compare/v0.12.23...v0.12.24) - Fix an edge case with direct `eval` and variable renaming Use of the direct `eval` construct causes all variable names in the scope containing the direct `eval` and all of its parent scopes to become "pinned" and unable to be renamed. This is because the dynamically-evaluated code is allowed to reference any of those variables by name. When this happens esbuild avoids renaming any of these variables, which effectively disables minification for most of the file, and avoids renaming any non-pinned variables to the name of a pinned variable. However, there was previously a bug where the pinned variable name avoidance only worked for pinned variables in the top-level scope but not in nested scopes. This could result in a non-pinned variable being incorrectly renamed to the name of a pinned variable in certain cases. For example: ```js // Input to esbuild return function($) { function foo(arg) { return arg + $; } // Direct "eval" here prevents "$" from being renamed // Repeated "$" puts "$" at the top of the character frequency histogram return eval(foo($$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$)) }(2); ``` When this code is minified with `--minify-identifiers`, the non-pinned variable `arg` is incorrectly transformed into `$` resulting in a name collision with the nested pinned variable `$`: ```js // Old output from esbuild (incorrect) return function($) { function foo($) { return $ + $; } return eval(foo($$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$)); }(2); ``` This is because the non-pinned variable `arg` is renamed to the top character in the character frequency histogram `$` (esbuild uses a character frequency histogram for smaller gzipped output sizes) and the pinned variable `$` was incorrectly not present in the list of variable names to avoid. With this release, the output is now correct: ```js // New output from esbuild (correct) return function($) { function foo(n) { return n + $; } return eval(foo($$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$)); }(2); ``` Note that even when esbuild handles direct `eval` correctly, using direct `eval` is not recommended because it disables minification for the file and likely won't work correctly in the presence of scope hoisting optimizations. See https://esbuild.github.io/link/direct-eval for more details. ### [`v0.12.23`](https://togithub.com/evanw/esbuild/blob/master/CHANGELOG.md#01223) [Compare Source](https://togithub.com/evanw/esbuild/compare/v0.12.22...v0.12.23) - Parsing of rest arguments in certain TypeScript types ([#1553](https://togithub.com/evanw/esbuild/issues/1553)) This release implements parsing of rest arguments inside object destructuring inside arrow functions inside TypeScript type declarations. Support for rest arguments in this specific syntax was not previously implemented. The following code was incorrectly considered a syntax error before this release, but is no longer considered a syntax error: ```ts type F = ({ ...rest }) => void; ``` - Fix error message for `watch: true` and `buildSync` ([#1552](https://togithub.com/evanw/esbuild/issues/1552)) Watch mode currently only works with the `build` API. Previously using watch mode with the `buildSync` API caused a confusing error message. This release explicitly disallows doing this, so the error message is now more clear. - Fix an minification bug with the `--keep-names` option ([#1552](https://togithub.com/evanw/esbuild/issues/1552)) This release fixes a subtle bug that happens with `--keep-names --minify` and nested function declarations in strict mode code. It can be triggered by the following code, which was being compiled incorrectly under those flags: ```js export function outer() { { function inner() { return Math.random(); } const x = inner(); console.log(x); } } outer(); ``` The bug was caused by an unfortunate interaction between a few of esbuild's behaviors: 1. Function declarations inside of nested scopes behave differently in different situations, so esbuild rewrites this function declaration to a local variable initialized to a function expression instead so that it behaves the same in all situations. More specifically, the interpretation of such function declarations depends on whether or not it currently exists in a strict mode context: > (function(){ { function x(){} } return x })() function x() {} > (function(){ 'use strict'; { function x(){} } return x })() ❌ Uncaught ReferenceError: x is not defined The bundling process sometimes erases strict mode context. For example, different files may have different strict mode status but may be merged into a single file which all shares the same strict mode status. Also, files in ESM format are automatically in strict mode but a bundle output file in IIFE format may not be executed in strict mode. Transforming the nested `function` to a `let` in strict mode and a `var` in non-strict mode means esbuild's output will behave reliably in different environments. 2. The "keep names" feature adds automatic calls to the built-in `__name` helper function to assign the original name to the `.name` property of the minified function object at run-time. That transforms the code into this: ```js let inner = function() { return Math.random(); }; __name(inner, "inner"); const x = inner(); console.log(x); ``` This injected helper call does not count as a use of the associated function object so that dead-code elimination will still remove the function object as dead code if nothing else uses it. Otherwise dead-code elimination would stop working when the "keep names" feature is enabled. 3. Minification enables an optimization where an initialized variable with a single use immediately following that variable is transformed by inlining the initializer into the use. So for example `var a = 1; return a` is transformed into `return 1`. This code matches this pattern (initialized single-use variable + use immediately following that variable) so the optimization does the inlining, which transforms the code into this: ```js __name(function() { return Math.random(); }, "inner"); const x = inner(); console.log(x); ``` The code is now incorrect because `inner` actually has two uses, although only one was actually counted. This inlining optimization will now be avoided in this specific case, which fixes the bug without regressing dead-code elimination or initialized variable inlining in any other cases.

Configuration

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

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

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

🔕 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.12.26 #478

Release Notes

Configuration

Codecov Report