chore(deps): update dependency esbuild to v0.14.16 #1469

renovate · 2022-01-31T23:03:32Z

renovate commented

2022-01-31 23:03:32 +00:00

This PR contains the following updates:

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

Release Notes

evanw/esbuild

`v0.14.16`

Compare Source

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:
```
// 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:
```
// 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:
```
// Original code
class Foo {
  static foo_;
}
Foo.foo_ = 0;

// New output (with --mangle-props=_ --target=es6)
class Foo {
}
__publicField(Foo, "a");
Foo.a = 0;
```

`v0.14.15`

Compare Source

Add property name mangling with --mangle-props= (#218)

⚠️ Using this feature can break your code in subtle ways. Do not use this feature unless you know what you are doing, and you know exactly how it will affect both your code and all of your dependencies. ⚠️

This release introduces property name mangling, which is similar to an existing feature from the popular UglifyJS and Terser JavaScript minifiers. This setting lets you pass a regular expression to esbuild to tell esbuild to automatically rename all properties that match this regular expression. It's useful when you want to minify certain property names in your code either to make the generated code smaller or to somewhat obfuscate your code's intent.

Here's an example that uses the regular expression _$ to mangle all properties ending in an underscore, such as foo_:

$ echo 'console.log({ foo_: 0 }.foo_)' | esbuild --mangle-props=_$
console.log({ a: 0 }.a);

Only mangling properties that end in an underscore is a reasonable heuristic because normal JS code doesn't typically contain identifiers like that. Browser APIs also don't use this naming convention so this also avoids conflicts with browser APIs. If you want to avoid mangling names such as __defineGetter__ you could consider using a more complex regular expression such as [^_]_$ (i.e. must end in a non-underscore followed by an underscore).

This is a separate setting instead of being part of the minify setting because it's an unsafe transformation that does not work on arbitrary JavaScript code. It only works if the provided regular expression matches all of the properties that you want mangled and does not match any of the properties that you don't want mangled. It also only works if you do not under any circumstances reference a property name to be mangled as a string. For example, it means you can't use Object.defineProperty(obj, 'prop', ...) or obj['prop'] with a mangled property. Specifically the following syntax constructs are the only ones eligible for property mangling:

Syntax	Example
Dot property access	`x.foo_`
Dot optional chain	`x?.foo_`
Object properties	`x = { foo_: y }`
Object methods	`x = { foo_() {} }`
Class fields	`class x { foo_ = y }`
Class methods	`class x { foo_() {} }`
Object destructuring binding	`let { foo_: x } = y`
Object destructuring assignment	`({ foo_: x } = y)`
JSX element names	`<X.foo_></X.foo_>`
JSX attribute names	`<X foo_={y} />`

You can avoid property mangling for an individual property by quoting it as a string. However, you must consistently use quotes or no quotes for a given property everywhere for this to work. For example, print({ foo_: 0 }.foo_) will be mangled into print({ a: 0 }.a) while print({ 'foo_': 0 }['foo_']) will not be mangled.

When using this feature, keep in mind that property names are only consistently mangled within a single esbuild API call but not across esbuild API calls. Each esbuild API call does an independent property mangling operation so output files generated by two different API calls may mangle the same property to two different names, which could cause the resulting code to behave incorrectly.

If you would like to exclude certain properties from mangling, you can reserve them with the --reserve-props= setting. For example, this uses the regular expression ^__.*__$ to reserve all properties that start and end with two underscores, such as __foo__:

$ echo 'console.log({ __foo__: 0 }.__foo__)' | esbuild --mangle-props=_$
console.log({ a: 0 }.a);

$ echo 'console.log({ __foo__: 0 }.__foo__)' | esbuild --mangle-props=_$ "--reserve-props=^__.*__$"
console.log({ __foo__: 0 }.__foo__);

Mark esbuild as supporting node v12+ (#1970)

Someone requested that esbuild populate the engines.node field in package.json. This release adds the following to each package.json file that esbuild publishes:
```
"engines": {
  "node": ">=12"
},
```
This was chosen because it's the oldest version of node that's currently still receiving support from the node team, and so is the oldest version of node that esbuild supports: https://nodejs.org/en/about/releases/.
Remove error recovery for invalid // comments in CSS (#1965)

Previously esbuild treated // as a comment in CSS and generated a warning, even though comments in CSS use /* ... */ instead. This allowed you to run esbuild on CSS intended for certain CSS preprocessors that support single-line comments.

However, some people are changing from another build tool to esbuild and have a code base that relies on // being preserved even though it's nonsense CSS and causes the entire surrounding rule to be discarded by the browser. Presumably this nonsense CSS ended up there at some point due to an incorrectly-configured build pipeline and the site now relies on that entire rule being discarded. If esbuild interprets // as a comment, it could cause the rule to no longer be discarded or even cause something else to happen.

With this release, esbuild no longer treats // as a comment in CSS. It still warns about it but now passes it through unmodified. This means it's no longer possible to run esbuild on CSS code containing single-line comments but it means that esbuild's behavior regarding these nonsensical CSS rules more accurately represents what happens in a browser.

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.14` -> `0.14.16`](https://renovatebot.com/diffs/npm/esbuild/0.14.14/0.14.16) | --- ### Release Notes <details> <summary>evanw/esbuild</summary> ### [`v0.14.16`](https://github.com/evanw/esbuild/blob/master/CHANGELOG.md#01416) [Compare Source](https://github.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; ``` ### [`v0.14.15`](https://github.com/evanw/esbuild/blob/master/CHANGELOG.md#01415) [Compare Source](https://github.com/evanw/esbuild/compare/v0.14.14...v0.14.15) - Add property name mangling with `--mangle-props=` ([#218](https://github.com/evanw/esbuild/issues/218)) ⚠️ **Using this feature can break your code in subtle ways.** Do not use this feature unless you know what you are doing, and you know exactly how it will affect both your code and all of your dependencies. ⚠️ This release introduces property name mangling, which is similar to an existing feature from the popular [UglifyJS](github.com/mishoo/uglifyjs) and [Terser](github.com/terser/terser) JavaScript minifiers. This setting lets you pass a regular expression to esbuild to tell esbuild to automatically rename all properties that match this regular expression. It's useful when you want to minify certain property names in your code either to make the generated code smaller or to somewhat obfuscate your code's intent. Here's an example that uses the regular expression `_$` to mangle all properties ending in an underscore, such as `foo_`: $ echo 'console.log({ foo_: 0 }.foo_)' | esbuild --mangle-props=_$ console.log({ a: 0 }.a); Only mangling properties that end in an underscore is a reasonable heuristic because normal JS code doesn't typically contain identifiers like that. Browser APIs also don't use this naming convention so this also avoids conflicts with browser APIs. If you want to avoid mangling names such as [`__defineGetter__`](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Object/\__defineGetter\_\_) you could consider using a more complex regular expression such as `[^_]_$` (i.e. must end in a non-underscore followed by an underscore). This is a separate setting instead of being part of the minify setting because it's an unsafe transformation that does not work on arbitrary JavaScript code. It only works if the provided regular expression matches all of the properties that you want mangled and does not match any of the properties that you don't want mangled. It also only works if you do not under any circumstances reference a property name to be mangled as a string. For example, it means you can't use `Object.defineProperty(obj, 'prop', ...)` or `obj['prop']` with a mangled property. Specifically the following syntax constructs are the only ones eligible for property mangling: | Syntax | Example | |---------------------------------|-------------------------| | Dot property access | `x.foo_` | | Dot optional chain | `x?.foo_` | | Object properties | `x = { foo_: y }` | | Object methods | `x = { foo_() {} }` | | Class fields | `class x { foo_ = y }` | | Class methods | `class x { foo_() {} }` | | Object destructuring binding | `let { foo_: x } = y` | | Object destructuring assignment | `({ foo_: x } = y)` | | JSX element names | `<X.foo_></X.foo_>` | | JSX attribute names | `<X foo_={y} />` | You can avoid property mangling for an individual property by quoting it as a string. However, you must consistently use quotes or no quotes for a given property everywhere for this to work. For example, `print({ foo_: 0 }.foo_)` will be mangled into `print({ a: 0 }.a)` while `print({ 'foo_': 0 }['foo_'])` will not be mangled. When using this feature, keep in mind that property names are only consistently mangled within a single esbuild API call but not across esbuild API calls. Each esbuild API call does an independent property mangling operation so output files generated by two different API calls may mangle the same property to two different names, which could cause the resulting code to behave incorrectly. If you would like to exclude certain properties from mangling, you can reserve them with the `--reserve-props=` setting. For example, this uses the regular expression `^__.*__$` to reserve all properties that start and end with two underscores, such as `__foo__`: $ echo 'console.log({ __foo__: 0 }.__foo__)' | esbuild --mangle-props=_$ console.log({ a: 0 }.a); $ echo 'console.log({ __foo__: 0 }.__foo__)' | esbuild --mangle-props=_$ "--reserve-props=^__.*__$" console.log({ __foo__: 0 }.__foo__); - Mark esbuild as supporting node v12+ ([#1970](https://github.com/evanw/esbuild/issues/1970)) Someone requested that esbuild populate the `engines.node` field in `package.json`. This release adds the following to each `package.json` file that esbuild publishes: ```json "engines": { "node": ">=12" }, ``` This was chosen because it's the oldest version of node that's currently still receiving support from the node team, and so is the oldest version of node that esbuild supports: https://nodejs.org/en/about/releases/. - Remove error recovery for invalid `//` comments in CSS ([#1965](https://github.com/evanw/esbuild/issues/1965)) Previously esbuild treated `//` as a comment in CSS and generated a warning, even though comments in CSS use `/* ... */` instead. This allowed you to run esbuild on CSS intended for certain CSS preprocessors that support single-line comments. However, some people are changing from another build tool to esbuild and have a code base that relies on `//` being preserved even though it's nonsense CSS and causes the entire surrounding rule to be discarded by the browser. Presumably this nonsense CSS ended up there at some point due to an incorrectly-configured build pipeline and the site now relies on that entire rule being discarded. If esbuild interprets `//` as a comment, it could cause the rule to no longer be discarded or even cause something else to happen. With this release, esbuild no longer treats `//` as a comment in CSS. It still warns about it but now passes it through unmodified. This means it's no longer possible to run esbuild on CSS code containing single-line comments but it means that esbuild's behavior regarding these nonsensical CSS rules more accurately represents what happens in a browser. </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-01-31 23:03:32 +00:00

frederick commented

2022-01-31 23:07:59 +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://1469-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://1469-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 changed title from ~~chore(deps): update dependency esbuild to v0.14.15~~ to chore(deps): update dependency esbuild to v0.14.16

2022-02-01 03:03:05 +00:00

renovate force-pushed renovate/esbuild-0.x from 5ef70457a3 to ec35f069b5

2022-02-01 03:03:05 +00:00

Compare

konrad merged commit 782e45eb8f into main

2022-02-01 06:56:13 +00:00

konrad deleted branch renovate/esbuild-0.x

2022-02-01 06:56:13 +00:00

konrad referenced this issue from a commit

2022-02-01 06:56:13 +00:00

chore(deps): update dependency esbuild to v0.14.16 (#1469)