Update dependency esbuild to v0.12.29

This PR contains the following updates:

Package	Change	Age	Adoption	Passing	Confidence
esbuild	`0.12.28` -> `0.12.29`

Release Notes

evanw/esbuild

### [`v0.12.29`](https://togithub.com/evanw/esbuild/blob/master/CHANGELOG.md#01229) [Compare Source](https://togithub.com/evanw/esbuild/compare/v0.12.28...v0.12.29) - Fix compilation of abstract class fields in TypeScript ([#1623](https://togithub.com/evanw/esbuild/issues/1623)) This release fixes a bug where esbuild could incorrectly include a TypeScript abstract class field in the compiled JavaScript output. This is incorrect because the official TypeScript compiler never does this. Note that this only happened in scenarios where TypeScript's `useDefineForClassFields` setting was set to `true` (or equivalently where TypeScript's `target` setting was set to `ESNext`). Here is the difference: ```js // Original code abstract class Foo { abstract foo: any; } // Old output class Foo { foo; } // New output class Foo { } ``` - Proxy from the `__require` shim to `require` ([#1614](https://togithub.com/evanw/esbuild/issues/1614)) Some background: esbuild's bundler emulates a CommonJS environment. The bundling process replaces the literal syntax `require()` with the referenced module at compile-time. However, other uses of `require` such as `require(someFunction())` are not bundled since the value of `someFunction()` depends on code evaluation, and esbuild does not evaluate code at compile-time. So it's possible for some references to `require` to remain after bundling. This was causing problems for some CommonJS code that was run in the browser and that expected `typeof require === 'function'` to be true (see [#1202](https://togithub.com/evanw/esbuild/issues/1202)), since the browser does not provide a global called `require`. Thus esbuild introduced a shim `require` function called `__require` (shown below) and replaced all references to `require` in the bundled code with `__require`: ```js var __require = x => { if (typeof require !== 'undefined') return require(x); throw new Error('Dynamic require of "' + x + '" is not supported'); }; ``` However, this broke code that referenced `require.resolve` inside the bundle, which could hypothetically actually work since you could assign your own implementation to `window.require.resolve` (see [#1579](https://togithub.com/evanw/esbuild/issues/1579)). So the implementation of `__require` was changed to this: ```js var __require = typeof require !== 'undefined' ? require : x => { throw new Error('Dynamic require of "' + x + '" is not supported'); }; ``` However, that broke code that assigned to `window.require` later on after the bundle was loaded ([#1614](https://togithub.com/evanw/esbuild/issues/1614)). So with this release, the code for `__require` now handles all of these edge cases: - `typeof require` is still `function` even if `window.require` is undefined - `window.require` can be assigned to either before or after the bundle is loaded - `require.resolve` and arbitrary other properties can still be accessed - `require` will now forward any number of arguments, not just the first one Handling all of these edge cases is only possible with the [Proxy API](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Proxy). So the implementation of `__require` now looks like this: ```js var __require = (x => typeof require !== 'undefined' ? require : typeof Proxy !== 'undefined' ? new Proxy(x, { get: (a, b) => (typeof require !== 'undefined' ? require : a)[b] }) : x )(function(x) { if (typeof require !== 'undefined') return require.apply(this, arguments); throw new Error('Dynamic require of "' + x + '" is not supported'); }); ``` - Consider `typeof x` to have no side effects The `typeof` operator does not itself trigger any code evaluation so it can safely be removed if evaluating the operand does not cause any side effects. However, there is a special case of the `typeof` operator when the operand is an identifier expression. In that case no reference error is thrown if the referenced symbol does not exist (e.g. `typeof x` does not throw an error if there is no symbol named `x`). With this release, esbuild will now consider `typeof x` to have no side effects even if evaluating `x` would have side effects (i.e. would throw a reference error): ```js // Original code var unused = typeof React !== 'undefined'; // Old output var unused = typeof React !== 'undefined'; // New output ``` Note that there is actually an edge case where `typeof x` *can* throw an error: when `x` is being referenced inside of its TDZ, or temporal dead zone (i.e. before it's declared). This applies to `let`, `const`, and `class` symbols. However, esbuild doesn't currently handle TDZ rules so the possibility of errors thrown due to TDZ rules is not currently considered. This typically doesn't matter in real-world code so this hasn't been a priority to fix (and is actually tricky to fix with esbuild's current bundling approach). So esbuild may incorrectly remove a `typeof` expression that actually has side effects. However, esbuild already incorrectly did this in previous releases so its behavior regarding `typeof` and TDZ rules hasn't changed in this release.

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.29 #490

Release Notes

Configuration

Codecov Report