chore(deps): update dependency esbuild to v0.14.17 #1477

renovate · 2022-02-02T05:05:57Z

renovate commented

2022-02-02 05:05:57 +00:00

This PR contains the following updates:

Package	Type	Update	Change
esbuild	devDependencies	patch	`0.14.16` -> `0.14.17`

Release Notes

evanw/esbuild

`v0.14.17`

Compare Source

Attempt to fix an install script issue on Ubuntu Linux (#1711)

There have been some reports of esbuild failing to install on Ubuntu Linux for a while now. I haven't been able to reproduce this myself due to lack of reproduction instructions until today, when I learned that the issue only happens when you install node from the Snap Store instead of downloading the official version of node.

The problem appears to be that when node is installed from the Snap Store, install scripts are run with stderr not being writable? This then appears to cause a problem for esbuild's install script when it uses execFileSync to validate that the esbuild binary is working correctly. This throws the error EACCES: permission denied, write even though this particular command never writes to stderr.

Node's documentation says that stderr for execFileSync defaults to that of the parent process. Forcing it to 'pipe' instead appears to fix the issue, although I still don't fully understand what's happening or why. I'm publishing this small change regardless to see if it fixes this install script edge case.
Avoid a syntax error due to --mangle-props=. and super() (#1976)

This release fixes an issue where passing --mangle-props=. (i.e. telling esbuild to mangle every single property) caused a syntax error with code like this:
```
class Foo {}
class Bar extends Foo {
  constructor() {
    super();
  }
}
```
The problem was that constructor was being renamed to another method, which then made it no longer a constructor, which meant that super() was now a syntax error. I have added a workaround that avoids renaming any property named constructor so that esbuild doesn't generate a syntax error here.

Despite this fix, I highly recommend not using --mangle-props=. because your code will almost certainly be broken. You will have to manually add every single property that you don't want mangled to --reserve-props= which is an excessive maintenance burden (e.g. reserve parse to use JSON.parse). Instead I recommend using a common pattern for all properties you intend to be mangled that is unlikely to appear in the APIs you use such as "ends in an underscore." This is an opt-in approach instead of an opt-out approach. It also makes it obvious when reading the code which properties will be mangled and which ones won't be.

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.14.16` -> `0.14.17`](https://renovatebot.com/diffs/npm/esbuild/0.14.16/0.14.17) | --- ### Release Notes <details> <summary>evanw/esbuild</summary> ### [`v0.14.17`](https://github.com/evanw/esbuild/blob/master/CHANGELOG.md#01417) [Compare Source](https://github.com/evanw/esbuild/compare/v0.14.16...v0.14.17) - Attempt to fix an install script issue on Ubuntu Linux ([#1711](https://github.com/evanw/esbuild/issues/1711)) There have been some reports of esbuild failing to install on Ubuntu Linux for a while now. I haven't been able to reproduce this myself due to lack of reproduction instructions until today, when I learned that the issue only happens when you install node from the [Snap Store](https://snapcraft.io/) instead of downloading the [official version of node](https://nodejs.org/dist/). The problem appears to be that when node is installed from the Snap Store, install scripts are run with stderr not being writable? This then appears to cause a problem for esbuild's install script when it uses `execFileSync` to validate that the esbuild binary is working correctly. This throws the error `EACCES: permission denied, write` even though this particular command never writes to stderr. Node's documentation says that stderr for `execFileSync` defaults to that of the parent process. Forcing it to `'pipe'` instead appears to fix the issue, although I still don't fully understand what's happening or why. I'm publishing this small change regardless to see if it fixes this install script edge case. - Avoid a syntax error due to `--mangle-props=.` and `super()` ([#1976](https://github.com/evanw/esbuild/issues/1976)) This release fixes an issue where passing `--mangle-props=.` (i.e. telling esbuild to mangle every single property) caused a syntax error with code like this: ```js class Foo {} class Bar extends Foo { constructor() { super(); } } ``` The problem was that `constructor` was being renamed to another method, which then made it no longer a constructor, which meant that `super()` was now a syntax error. I have added a workaround that avoids renaming any property named `constructor` so that esbuild doesn't generate a syntax error here. Despite this fix, I highly recommend not using `--mangle-props=.` because your code will almost certainly be broken. You will have to manually add every single property that you don't want mangled to `--reserve-props=` which is an excessive maintenance burden (e.g. reserve `parse` to use `JSON.parse`). Instead I recommend using a common pattern for all properties you intend to be mangled that is unlikely to appear in the APIs you use such as "ends in an underscore." This is an opt-in approach instead of an opt-out approach. It also makes it obvious when reading the code which properties will be mangled and which ones won't be. </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 2022-02-02 05:05:57 +00:00

frederick commented

2022-02-02 05:10:53 +00:00

Hi renovate!

Thank you for creating a PR!

I've deployed the changes of this PR on a preview environment under this URL: https://1477-renovateesbuild-0.x--vikunja-frontend-preview.netlify.app

You can use this url to view the changes live and test them out.
You will need to manually connect this to an api running somehwere. The easiest to use is https://try.vikunja.io/.

Have a nice day!

Beep boop, I'm a bot.

Hi renovate! Thank you for creating a PR! I've deployed the changes of this PR on a preview environment under this URL: https://1477-renovateesbuild-0.x--vikunja-frontend-preview.netlify.app You can use this url to view the changes live and test them out. You will need to manually connect this to an api running somehwere. The easiest to use is https://try.vikunja.io/. Have a nice day! > Beep boop, I'm a bot.

renovate force-pushed renovate/esbuild-0.x from 9f3ddf0a3c to fee62c83ec

2022-02-02 07:02:51 +00:00

Compare

konrad merged commit 6a833bd8c4 into main

2022-02-02 07:40:46 +00:00

konrad deleted branch renovate/esbuild-0.x

2022-02-02 07:40:46 +00:00

konrad referenced this issue from a commit

2022-02-02 07:40:46 +00:00

chore(deps): update dependency esbuild to v0.14.17 (#1477)

This repo is archived. You cannot comment on pull requests.

No reviewers