chore(deps): update dependency esbuild to v0.14.18

This PR contains the following updates:

Package	Change	Age	Adoption	Passing	Confidence
esbuild	`0.14.15` -> `0.14.18`

Release Notes

evanw/esbuild

### [`v0.14.18`](https://togithub.com/evanw/esbuild/blob/HEAD/CHANGELOG.md#01418) [Compare Source](https://togithub.com/evanw/esbuild/compare/v0.14.17...v0.14.18) - Add the `--mangle-cache=` feature ([#1977](https://togithub.com/evanw/esbuild/issues/1977)) This release adds a cache API for the newly-released `--mangle-props=` feature. When enabled, all mangled property renamings are recorded in the cache during the initial build. Subsequent builds reuse the renamings stored in the cache and add additional renamings for any newly-added properties. This has a few consequences: - You can customize what mangled properties are renamed to by editing the cache before passing it to esbuild (the cache is a map of the original name to the mangled name). - The cache serves as a list of all properties that were mangled. You can easily scan it to see if there are any unexpected property renamings. - You can disable mangling for individual properties by setting the renamed value to `false` instead of to a string. This is similar to the `--reserve-props=` setting but on a per-property basis. - You can ensure consistent renaming between builds (e.g. a main-thread file and a web worker, or a library and a plugin). Without this feature, each build would do an independent renaming operation and the mangled property names likely wouldn't be consistent. Here's how to use it: - CLI ```sh $ esbuild example.ts --mangle-props=_$ --mangle-cache=cache.json ``` - JS API ```js let result = await esbuild.build({ entryPoints: ['example.ts'], mangleProps: /_$/, mangleCache: { customRenaming_: '__c', disabledRenaming_: false, }, }) let updatedMangleCache = result.mangleCache ``` - Go API ```go result := api.Build(api.BuildOptions{ EntryPoints: []string{"example.ts"}, MangleProps: "_$", MangleCache: map[string]interface{}{ "customRenaming_": "__c", "disabledRenaming_": false, }, }) updatedMangleCache := result.MangleCache ``` The above code would do something like the following: ```js // Original code x = { customRenaming_: 1, disabledRenaming_: 2, otherProp_: 3, } // Generated code x = { __c: 1, disabledRenaming_: 2, a: 3 }; // Updated mangle cache { "customRenaming_": "__c", "disabledRenaming_": false, "otherProp_": "a" } ``` - Add `opera` and `ie` as possible target environments You can now target [Opera](https://www.opera.com/) and/or [Internet Explorer](https://www.microsoft.com/en-us/download/internet-explorer.aspx) using the `--target=` setting. For example, `--target=opera45,ie9` targets Opera 45 and Internet Explorer 9. This change does not add any additional features to esbuild's code transformation pipeline to transform newer syntax so that it works in Internet Explorer. It just adds information about what features are supported in these browsers to esbuild's internal feature compatibility table. - Minify `typeof x !== 'undefined'` to `typeof x < 'u'` This release introduces a small improvement for code that does a lot of `typeof` checks against `undefined`: ```js // Original code y = typeof x !== 'undefined'; // Old output (with --minify) y=typeof x!="undefined"; // New output (with --minify) y=typeof x<"u"; ``` This transformation is only active when minification is enabled, and is disabled if the language target is set lower than ES2020 or if Internet Explorer is set as a target environment. Before ES2020, implementations were allowed to return non-standard values from the `typeof` operator for a few objects. Internet Explorer took advantage of this to sometimes return the string `'unknown'` instead of `'undefined'`. But this has been removed from the specification and Internet Explorer was the only engine to do this, so this minification is valid for code that does not need to target Internet Explorer. ### [`v0.14.17`](https://togithub.com/evanw/esbuild/blob/HEAD/CHANGELOG.md#01417) [Compare Source](https://togithub.com/evanw/esbuild/compare/v0.14.16...v0.14.17) - Attempt to fix an install script issue on Ubuntu Linux ([#1711](https://togithub.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://togithub.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. ### [`v0.14.16`](https://togithub.com/evanw/esbuild/blob/HEAD/CHANGELOG.md#01416) [Compare Source](https://togithub.com/evanw/esbuild/compare/v0.14.15...v0.14.16) - Support property name mangling with some TypeScript syntax features The newly-released `--mangle-props=` feature previously only affected JavaScript syntax features. This release adds support for using mangle props with certain TypeScript syntax features: - **TypeScript parameter properties** Parameter properties are a TypeScript-only shorthand way of initializing a class field directly from the constructor argument list. Previously parameter properties were not treated as properties to be mangled. They should now be handled correctly: ```ts // Original code class Foo { constructor(public foo_) {} } new Foo().foo_; // Old output (with --minify --mangle-props=_) class Foo{constructor(c){this.foo_=c}}new Foo().o; // New output (with --minify --mangle-props=_) class Foo{constructor(o){this.c=o}}new Foo().c; ``` - **TypeScript namespaces** Namespaces are a TypeScript-only way to add properties to an object. Previously exported namespace members were not treated as properties to be mangled. They should now be handled correctly: ```ts // Original code namespace ns { export let foo_ = 1; export function bar_(x) {} } ns.bar_(ns.foo_); // Old output (with --minify --mangle-props=_) var ns;(e=>{e.foo_=1;function t(a){}e.bar_=t})(ns||={}),ns.e(ns.o); // New output (with --minify --mangle-props=_) var ns;(e=>{e.e=1;function o(p){}e.t=o})(ns||={}),ns.t(ns.e); ``` - Fix property name mangling for lowered class fields This release fixes a compiler crash with `--mangle-props=` and class fields that need to be transformed to older versions of JavaScript. The problem was that doing this is an unusual case where the mangled property name must be represented as a string instead of as a property name, which previously wasn't implemented. This case should now work correctly: ```js // Original code class Foo { static foo_; } Foo.foo_ = 0; // New output (with --mangle-props=_ --target=es6) class Foo { } __publicField(Foo, "a"); Foo.a = 0; ```

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, click this checkbox.

This PR has been generated by WhiteSource Renovate. View repository job log here.

serialport / bindings-cpp

chore(deps): update dependency esbuild to v0.14.18 #27

Release Notes

Configuration