chore(deps): update dependency esbuild to v0.12.29 #769

renovate · 2021-09-22T06:01:27Z

renovate commented

2021-09-22 06:01:27 +00:00

This PR contains the following updates:

Package	Type	Update	Change
esbuild	devDependencies	patch	`0.12.28` -> `0.12.29`

Release Notes

evanw/esbuild

`v0.12.29`

Compare Source

Fix compilation of abstract class fields in TypeScript (#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:
```
// 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)

Some background: esbuild's bundler emulates a CommonJS environment. The bundling process replaces the literal syntax require(<string>) 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), 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:
```
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). So the implementation of __require was changed to this:
```
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). 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. So the implementation of __require now looks like this:
```
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):
```
// 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: 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, check this box.

This PR has been generated by Renovate Bot.

This PR contains the following updates: | Package | Type | Update | Change | |---|---|---|---| | [esbuild](https://github.com/evanw/esbuild) | devDependencies | patch | [`0.12.28` -> `0.12.29`](https://renovatebot.com/diffs/npm/esbuild/0.12.28/0.12.29) | --- ### Release Notes <details> <summary>evanw/esbuild</summary> ### [`v0.12.29`](https://github.com/evanw/esbuild/blob/master/CHANGELOG.md#01229) [Compare Source](https://github.com/evanw/esbuild/compare/v0.12.28...v0.12.29) - Fix compilation of abstract class fields in TypeScript ([#1623](https://github.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://github.com/evanw/esbuild/issues/1614)) Some background: esbuild's bundler emulates a CommonJS environment. The bundling process replaces the literal syntax `require(<string>)` 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://github.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://github.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://github.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. </details> --- ### Configuration 📅 **Schedule**: At any time (no schedule defined). 🚦 **Automerge**: Disabled by config. Please merge this manually once you are satisfied. ♻ **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, check this box. --- This PR has been generated by [Renovate Bot](https://github.com/renovatebot/renovate).

renovate added the

dependencies

label 2021-09-22 06:01:27 +00:00

renovate added 1 commit 2021-09-22 06:01:27 +00:00