evanw/esbuild
### [`v0.17.11`](https://togithub.com/evanw/esbuild/blob/HEAD/CHANGELOG.md#01711)
[Compare Source](https://togithub.com/evanw/esbuild/compare/v0.17.10...v0.17.11)
- Fix the `alias` feature to always prefer the longest match ([#2963](https://togithub.com/evanw/esbuild/issues/2963))
It's possible to configure conflicting aliases such as `--alias:a=b` and `--alias:a/c=d`, which is ambiguous for the import path `a/c/x` (since it could map to either `b/c/x` or `d/x`). Previously esbuild would pick the first matching `alias`, which would non-deterministically pick between one of the possible matches. This release fixes esbuild to always deterministically pick the longest possible match.
- Minify calls to some global primitive constructors ([#2962](https://togithub.com/evanw/esbuild/issues/2962))
With this release, esbuild's minifier now replaces calls to `Boolean`/`Number`/`String`/`BigInt` with equivalent shorter code when relevant:
```js
// Original code
console.log(
Boolean(a ? (b | c) !== 0 : (c & d) !== 0),
Number(e ? '1' : '2'),
String(e ? '1' : '2'),
BigInt(e ? 1n : 2n),
)
// Old output (with --minify)
console.log(Boolean(a?(b|c)!==0:(c&d)!==0),Number(e?"1":"2"),String(e?"1":"2"),BigInt(e?1n:2n));
// New output (with --minify)
console.log(!!(a?b|c:c&d),+(e?"1":"2"),e?"1":"2",e?1n:2n);
```
- Adjust some feature compatibility tables for node ([#2940](https://togithub.com/evanw/esbuild/issues/2940))
This release makes the following adjustments to esbuild's internal feature compatibility tables for node, which tell esbuild which versions of node are known to support all aspects of that feature:
- `class-private-brand-checks`: node v16.9+ => node v16.4+ (a decrease)
- `hashbang`: node v12.0+ => node v12.5+ (an increase)
- `optional-chain`: node v16.9+ => node v16.1+ (a decrease)
- `template-literal`: node v4+ => node v10+ (an increase)
Each of these adjustments was identified by comparing against data from the `node-compat-table` package and was manually verified using old node executables downloaded from https://nodejs.org/download/release/.
### [`v0.17.10`](https://togithub.com/evanw/esbuild/blob/HEAD/CHANGELOG.md#01710)
[Compare Source](https://togithub.com/evanw/esbuild/compare/v0.17.9...v0.17.10)
- Update esbuild's handling of CSS nesting to match the latest specification changes ([#1945](https://togithub.com/evanw/esbuild/issues/1945))
The syntax for the upcoming CSS nesting feature has [recently changed](https://webkit.org/blog/13813/try-css-nesting-today-in-safari-technology-preview/). The `@nest` prefix that was previously required in some cases is now gone, and nested rules no longer have to start with `&` (as long as they don't start with an identifier or function token).
This release updates esbuild's pass-through handling of CSS nesting syntax to match the latest specification changes. So you can now use esbuild to bundle CSS containing nested rules and try them out in a browser that supports CSS nesting (which includes nightly builds of both Chrome and Safari).
However, I'm not implementing lowering of nested CSS to non-nested CSS for older browsers yet. While the syntax has been decided, the semantics are still in flux. In particular, there is still some debate about changing the fundamental way that CSS nesting works. For example, you might think that the following CSS is equivalent to a `.outer .inner button { ... }` rule:
```css
.inner button {
.outer & {
color: red;
}
}
```
But instead it's actually equivalent to a `.outer :is(.inner button) { ... }` rule which unintuitively also matches the following DOM structure:
```html
```
The `:is()` behavior is preferred by browser implementers because it's more memory-efficient, but the straightforward translation into a `.outer .inner button { ... }` rule is preferred by developers used to the existing CSS preprocessing ecosystem (e.g. SASS). It seems premature to commit esbuild to specific semantics for this syntax at this time given the ongoing debate.
- Fix cross-file CSS rule deduplication involving `url()` tokens ([#2936](https://togithub.com/evanw/esbuild/issues/2936))
Previously cross-file CSS rule deduplication didn't handle `url()` tokens correctly. These tokens contain references to import paths which may be internal (i.e. in the bundle) or external (i.e. not in the bundle). When comparing two `url()` tokens for equality, the underlying import paths should be compared instead of their references. This release of esbuild fixes `url()` token comparisons. One side effect is that `@font-face` rules should now be deduplicated correctly across files:
```css
/* Original code */
@import "data:text/css, \
@import 'http://example.com/style.css'; \
@font-face { src: url(http://example.com/font.ttf) }";
@import "data:text/css, \
@font-face { src: url(http://example.com/font.ttf) }";
/* Old output (with --bundle --minify) */
@import"http://example.com/style.css";@font-face{src:url(http://example.com/font.ttf)}@font-face{src:url(http://example.com/font.ttf)}
/* New output (with --bundle --minify) */
@import"http://example.com/style.css";@font-face{src:url(http://example.com/font.ttf)}
```
### [`v0.17.9`](https://togithub.com/evanw/esbuild/blob/HEAD/CHANGELOG.md#0179)
[Compare Source](https://togithub.com/evanw/esbuild/compare/v0.17.8...v0.17.9)
- Parse rest bindings in TypeScript types ([#2937](https://togithub.com/evanw/esbuild/issues/2937))
Previously esbuild was unable to parse the following valid TypeScript code:
```ts
let tuple: (...[e1, e2, ...es]: any) => any
```
This release includes support for parsing code like this.
- Fix TypeScript code translation for certain computed `declare` class fields ([#2914](https://togithub.com/evanw/esbuild/issues/2914))
In TypeScript, the key of a computed `declare` class field should only be preserved if there are no decorators for that field. Previously esbuild always preserved the key, but esbuild will now remove the key to match the output of the TypeScript compiler:
```ts
// Original code
declare function dec(a: any, b: any): any
declare const removeMe: unique symbol
declare const keepMe: unique symbol
class X {
declare [removeMe]: any
@dec declare [keepMe]: any
}
// Old output
var _a;
class X {
}
removeMe, _a = keepMe;
__decorateClass([
dec
], X.prototype, _a, 2);
// New output
var _a;
class X {
}
_a = keepMe;
__decorateClass([
dec
], X.prototype, _a, 2);
```
- Fix a crash with path resolution error generation ([#2913](https://togithub.com/evanw/esbuild/issues/2913))
In certain situations, a module containing an invalid import path could previously cause esbuild to crash when it attempts to generate a more helpful error message. This crash has been fixed.
### [`v0.17.8`](https://togithub.com/evanw/esbuild/blob/HEAD/CHANGELOG.md#0178)
[Compare Source](https://togithub.com/evanw/esbuild/compare/v0.17.7...v0.17.8)
- Fix a minification bug with non-ASCII identifiers ([#2910](https://togithub.com/evanw/esbuild/issues/2910))
This release fixes a bug with esbuild where non-ASCII identifiers followed by a keyword were incorrectly not separated by a space. This bug affected both the `in` and `instanceof` keywords. Here's an example of the fix:
```js
// Original code
Ο in a
// Old output (with --minify --charset=utf8)
Οin a;
// New output (with --minify --charset=utf8)
Ο in a;
```
- Fix a regression with esbuild's WebAssembly API in version 0.17.6 ([#2911](https://togithub.com/evanw/esbuild/issues/2911))
Version 0.17.6 of esbuild updated the Go toolchain to version 1.20.0. This had the unfortunate side effect of increasing the amount of stack space that esbuild uses (presumably due to some changes to Go's WebAssembly implementation) which could cause esbuild's WebAssembly-based API to crash with a stack overflow in cases where it previously didn't crash. One such case is the package `grapheme-splitter` which contains code that looks like this:
```js
if (
(0x0300 <= code && code <= 0x036F) ||
(0x0483 <= code && code <= 0x0487) ||
(0x0488 <= code && code <= 0x0489) ||
(0x0591 <= code && code <= 0x05BD) ||
// ... many hundreds of lines later ...
) {
return;
}
```
This edge case involves a chain of binary operators that results in an AST over 400 nodes deep. Normally this wouldn't be a problem because Go has growable call stacks, so the call stack would just grow to be as large as needed. However, WebAssembly byte code deliberately doesn't expose the ability to manipulate the stack pointer, so Go's WebAssembly translation is forced to use the fixed-size WebAssembly call stack. So esbuild's WebAssembly implementation is vulnerable to stack overflow in cases like these.
It's not unreasonable for this to cause a stack overflow, and for esbuild's answer to this problem to be "don't write code like this." That's how many other AST-manipulation tools handle this problem. However, it's possible to implement AST traversal using iteration instead of recursion to work around limited call stack space. This version of esbuild implements this code transformation for esbuild's JavaScript parser and printer, so esbuild's WebAssembly implementation is now able to process the `grapheme-splitter` package (at least when compiled with Go 1.20.0 and run with node's WebAssembly implementation).
### [`v0.17.7`](https://togithub.com/evanw/esbuild/blob/HEAD/CHANGELOG.md#0177)
[Compare Source](https://togithub.com/evanw/esbuild/compare/v0.17.6...v0.17.7)
- Change esbuild's parsing of TypeScript instantiation expressions to match TypeScript 4.8+ ([#2907](https://togithub.com/evanw/esbuild/issues/2907))
This release updates esbuild's implementation of instantiation expression erasure to match [microsoft/TypeScript#49353](https://togithub.com/microsoft/TypeScript/pull/49353). The new rules are as follows (copied from TypeScript's PR description):
> When a potential type argument list is followed by
>
> - a line break,
> - an `(` token,
> - a template literal string, or
> - any token except `<` or `>` that isn't the start of an expression,
>
> we consider that construct to be a type argument list. Otherwise we consider the construct to be a `<` relational expression followed by a `>` relational expression.
- Ignore `sideEffects: false` for imported CSS files ([#1370](https://togithub.com/evanw/esbuild/issues/1370), [#1458](https://togithub.com/evanw/esbuild/pull/1458), [#2905](https://togithub.com/evanw/esbuild/issues/2905))
This release ignores the `sideEffects` annotation in `package.json` for CSS files that are imported into JS files using esbuild's `css` loader. This means that these CSS files are no longer be tree-shaken.
Importing CSS into JS causes esbuild to automatically create a CSS entry point next to the JS entry point containing the bundled CSS. Previously packages that specified some form of `"sideEffects": false` could potentially cause esbuild to consider one or more of the JS files on the import path to the CSS file to be side-effect free, which would result in esbuild removing that CSS file from the bundle. This was problematic because the removal of that CSS is outwardly observable, since all CSS is global, so it was incorrect for previous versions of esbuild to tree-shake CSS files imported into JS files.
- Add constant folding for certain additional equality cases ([#2394](https://togithub.com/evanw/esbuild/issues/2394), [#2895](https://togithub.com/evanw/esbuild/issues/2895))
This release adds constant folding for expressions similar to the following:
```js
// Original input
console.log(
null === 'foo',
null === undefined,
null == undefined,
false === 0,
false == 0,
1 === true,
1 == true,
)
// Old output
console.log(
null === "foo",
null === void 0,
null == void 0,
false === 0,
false == 0,
1 === true,
1 == true
);
// New output
console.log(
false,
false,
true,
false,
true,
false,
true
);
```
Configuration
π Schedule: Branch creation - At any time (no schedule defined), Automerge - 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 Mend Renovate. View repository job log here.
This PR contains the following updates:
0.17.6->0.17.11Release Notes
evanw/esbuild
### [`v0.17.11`](https://togithub.com/evanw/esbuild/blob/HEAD/CHANGELOG.md#01711) [Compare Source](https://togithub.com/evanw/esbuild/compare/v0.17.10...v0.17.11) - Fix the `alias` feature to always prefer the longest match ([#2963](https://togithub.com/evanw/esbuild/issues/2963)) It's possible to configure conflicting aliases such as `--alias:a=b` and `--alias:a/c=d`, which is ambiguous for the import path `a/c/x` (since it could map to either `b/c/x` or `d/x`). Previously esbuild would pick the first matching `alias`, which would non-deterministically pick between one of the possible matches. This release fixes esbuild to always deterministically pick the longest possible match. - Minify calls to some global primitive constructors ([#2962](https://togithub.com/evanw/esbuild/issues/2962)) With this release, esbuild's minifier now replaces calls to `Boolean`/`Number`/`String`/`BigInt` with equivalent shorter code when relevant: ```js // Original code console.log( Boolean(a ? (b | c) !== 0 : (c & d) !== 0), Number(e ? '1' : '2'), String(e ? '1' : '2'), BigInt(e ? 1n : 2n), ) // Old output (with --minify) console.log(Boolean(a?(b|c)!==0:(c&d)!==0),Number(e?"1":"2"),String(e?"1":"2"),BigInt(e?1n:2n)); // New output (with --minify) console.log(!!(a?b|c:c&d),+(e?"1":"2"),e?"1":"2",e?1n:2n); ``` - Adjust some feature compatibility tables for node ([#2940](https://togithub.com/evanw/esbuild/issues/2940)) This release makes the following adjustments to esbuild's internal feature compatibility tables for node, which tell esbuild which versions of node are known to support all aspects of that feature: - `class-private-brand-checks`: node v16.9+ => node v16.4+ (a decrease) - `hashbang`: node v12.0+ => node v12.5+ (an increase) - `optional-chain`: node v16.9+ => node v16.1+ (a decrease) - `template-literal`: node v4+ => node v10+ (an increase) Each of these adjustments was identified by comparing against data from the `node-compat-table` package and was manually verified using old node executables downloaded from https://nodejs.org/download/release/. ### [`v0.17.10`](https://togithub.com/evanw/esbuild/blob/HEAD/CHANGELOG.md#01710) [Compare Source](https://togithub.com/evanw/esbuild/compare/v0.17.9...v0.17.10) - Update esbuild's handling of CSS nesting to match the latest specification changes ([#1945](https://togithub.com/evanw/esbuild/issues/1945)) The syntax for the upcoming CSS nesting feature has [recently changed](https://webkit.org/blog/13813/try-css-nesting-today-in-safari-technology-preview/). The `@nest` prefix that was previously required in some cases is now gone, and nested rules no longer have to start with `&` (as long as they don't start with an identifier or function token). This release updates esbuild's pass-through handling of CSS nesting syntax to match the latest specification changes. So you can now use esbuild to bundle CSS containing nested rules and try them out in a browser that supports CSS nesting (which includes nightly builds of both Chrome and Safari). However, I'm not implementing lowering of nested CSS to non-nested CSS for older browsers yet. While the syntax has been decided, the semantics are still in flux. In particular, there is still some debate about changing the fundamental way that CSS nesting works. For example, you might think that the following CSS is equivalent to a `.outer .inner button { ... }` rule: ```css .inner button { .outer & { color: red; } } ``` But instead it's actually equivalent to a `.outer :is(.inner button) { ... }` rule which unintuitively also matches the following DOM structure: ```htmlConfiguration
π Schedule: Branch creation - At any time (no schedule defined), Automerge - 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.
This PR has been generated by Mend Renovate. View repository job log here.