evanw/esbuild
### [`v0.15.14`](https://togithub.com/evanw/esbuild/blob/HEAD/CHANGELOG.md#01514)
[Compare Source](https://togithub.com/evanw/esbuild/compare/v0.15.13...v0.15.14)
- Fix parsing of TypeScript `infer` inside a conditional `extends` ([#2675](https://togithub.com/evanw/esbuild/issues/2675))
Unlike JavaScript, parsing TypeScript sometimes requires backtracking. The `infer A` type operator can take an optional constraint of the form `infer A extends B`. However, this syntax conflicts with the similar conditional type operator `A extends B ? C : D` in cases where the syntax is combined, such as `infer A extends B ? C : D`. This is supposed to be parsed as `(infer A) extends B ? C : D`. Previously esbuild incorrectly parsed this as `(infer A extends B) ? C : D` instead, which is a parse error since the `?:` conditional operator requires the `extends` keyword as part of the conditional type. TypeScript disambiguates by speculatively parsing the `extends` after the `infer`, but backtracking if a `?` token is encountered afterward. With this release, esbuild should now do the same thing, so esbuild should now correctly parse these types. Here's a real-world example of such a type:
```ts
type Normalized = T extends Array
? Dictionary>
: {
[P in keyof T]: T[P] extends Array
? Dictionary>
: Normalized
}
```
- Avoid unnecessary watch mode rebuilds when debug logging is enabled ([#2661](https://togithub.com/evanw/esbuild/issues/2661))
When debug-level logs are enabled (such as with `--log-level=debug`), esbuild's path resolution subsystem generates debug log messages that say something like "Read 20 entries for directory /home/user" to help you debug what esbuild's path resolution is doing. This caused esbuild's watch mode subsystem to add a dependency on the full list of entries in that directory since if that changes, the generated log message would also have to be updated. However, meant that on systems where a parent directory undergoes constant directory entry churn, esbuild's watch mode would continue to rebuild if `--log-level=debug` was passed.
With this release, these debug log messages are now generated by "peeking" at the file system state while bypassing esbuild's watch mode dependency tracking. So now watch mode doesn't consider the count of directory entries in these debug log messages to be a part of the build that needs to be kept up to date when the file system state changes.
### [`v0.15.13`](https://togithub.com/evanw/esbuild/blob/HEAD/CHANGELOG.md#01513)
[Compare Source](https://togithub.com/evanw/esbuild/compare/v0.15.12...v0.15.13)
- Add support for the TypeScript 4.9 `satisfies` operator ([#2509](https://togithub.com/evanw/esbuild/pull/2509))
TypeScript 4.9 introduces a new operator called `satisfies` that lets you check that a given value satisfies a less specific type without casting it to that less specific type and without generating any additional code at run-time. It looks like this:
```ts
const value = { foo: 1, bar: false } satisfies Record
console.log(value.foo.toFixed(1)) // TypeScript knows that "foo" is a number here
```
Before this existed, you could use a cast with `as` to check that a value satisfies a less specific type, but that removes any additional knowledge that TypeScript has about that specific value:
```ts
const value = { foo: 1, bar: false } as Record
console.log(value.foo.toFixed(1)) // TypeScript no longer knows that "foo" is a number
```
You can read more about this feature in [TypeScript's blog post for 4.9](https://devblogs.microsoft.com/typescript/announcing-typescript-4-9-rc/#the-satisfies-operator) as well as [the associated TypeScript issue for this feature](https://togithub.com/microsoft/TypeScript/issues/47920).
This feature was implemented in esbuild by [@magic-akari](https://togithub.com/magic-akari).
- Fix watch mode constantly rebuilding if the parent directory is inaccessible ([#2640](https://togithub.com/evanw/esbuild/issues/2640))
Android is unusual in that it has an inaccessible directory in the path to the root, which esbuild was not originally built to handle. To handle cases like this, the path resolution layer in esbuild has a hack where it treats inaccessible directories as empty. However, esbuild's watch implementation currently triggers a rebuild if a directory previously encountered an error but the directory now exists. The assumption is that the previous error was caused by the directory not existing. Although that's usually the case, it's not the case for this particular parent directory on Android. Instead the error is that the directory previously existed but was inaccessible.
This discrepancy between esbuild's path resolution layer and its watch mode was causing watch mode to rebuild continuously on Android. With this release, esbuild's watch mode instead checks for an error status change in the `readdir` file system call, so watch mode should no longer rebuild continuously on Android.
- Apply a fix for a rare deadlock with the JavaScript API ([#1842](https://togithub.com/evanw/esbuild/issues/1842), [#2485](https://togithub.com/evanw/esbuild/issues/2485))
There have been reports of esbuild sometimes exiting with an "all goroutines are asleep" deadlock message from the Go language runtime. This issue hasn't made much progress until recently, where a possible cause was discovered (thanks to [@jfirebaugh](https://togithub.com/jfirebaugh) for the investigation). This release contains a possible fix for that possible cause, so this deadlock may have been fixed. The fix cannot be easily verified because the deadlock is non-deterministic and rare. If this was indeed the cause, then this issue only affected the JavaScript API in situations where esbuild was already in the process of exiting.
In detail: The underlying cause is that Go's [`sync.WaitGroup`](https://pkg.go.dev/sync#WaitGroup) API for waiting for a set of goroutines to finish is not fully thread-safe. Specifically it's not safe to call `Add()` concurrently with `Wait()` when the wait group counter is zero due to a data race. This situation could come up with esbuild's JavaScript API when the host JavaScript process closes the child process's stdin and the child process (with no active tasks) calls `Wait()` to check that there are no active tasks, at the same time as esbuild's watchdog timer calls `Add()` to add an active task (that pings the host to see if it's still there). The fix in this release is to avoid calling `Add()` once we learn that stdin has been closed but before we call `Wait()`.
### [`v0.15.12`](https://togithub.com/evanw/esbuild/blob/HEAD/CHANGELOG.md#01512)
[Compare Source](https://togithub.com/evanw/esbuild/compare/v0.15.11...v0.15.12)
- Fix minifier correctness bug with single-use substitutions ([#2619](https://togithub.com/evanw/esbuild/issues/2619))
When minification is enabled, esbuild will attempt to eliminate variables that are only used once in certain cases. For example, esbuild minifies this code:
```js
function getEmailForUser(name) {
let users = db.table('users');
let user = users.find({ name });
let email = user?.get('email');
return email;
}
```
into this code:
```js
function getEmailForUser(e){return db.table("users").find({name:e})?.get("email")}
```
However, this transformation had a bug where esbuild did not correctly consider the "read" part of binary read-modify-write assignment operators. For example, it's incorrect to minify the following code into `bar += fn()` because the call to `fn()` might modify `bar`:
```js
const foo = fn();
bar += foo;
```
In addition to fixing this correctness bug, this release also improves esbuild's output in the case where all values being skipped over are primitives:
```js
function toneMapLuminance(r, g, b) {
let hdr = luminance(r, g, b)
let decay = 1 / (1 + hdr)
return 1 - decay
}
```
Previous releases of esbuild didn't substitute these single-use variables here, but esbuild will now minify this to the following code starting with this release:
```js
function toneMapLuminance(e,n,a){return 1-1/(1+luminance(e,n,a))}
```
### [`v0.15.11`](https://togithub.com/evanw/esbuild/blob/HEAD/CHANGELOG.md#01511)
[Compare Source](https://togithub.com/evanw/esbuild/compare/v0.15.10...v0.15.11)
- Fix various edge cases regarding template tags and `this` ([#2610](https://togithub.com/evanw/esbuild/issues/2610))
This release fixes some bugs where the value of `this` wasn't correctly preserved when evaluating template tags in a few edge cases. These edge cases are listed below:
```js
async function test() {
class Foo { foo() { return this } }
class Bar extends Foo {
a = async () => super.foo``
b = async () => super['foo']``
c = async (foo) => super[foo]``
}
function foo() { return this }
const obj = { foo }
const bar = new Bar
console.log(
(await bar.a()) === bar,
(await bar.b()) === bar,
(await bar.c('foo')) === bar,
{ foo }.foo``.foo === foo,
(true && obj.foo)`` !== obj,
(false || obj.foo)`` !== obj,
(null ?? obj.foo)`` !== obj,
)
}
test()
```
Each edge case in the code above previously incorrectly printed `false` when run through esbuild with `--minify --target=es6` but now correctly prints `true`. These edge cases are unlikely to have affected real-world code.
### [`v0.15.10`](https://togithub.com/evanw/esbuild/blob/HEAD/CHANGELOG.md#01510)
[Compare Source](https://togithub.com/evanw/esbuild/compare/v0.15.9...v0.15.10)
- Add support for node's "pattern trailers" syntax ([#2569](https://togithub.com/evanw/esbuild/issues/2569))
After esbuild implemented node's `exports` feature in `package.json`, node changed the feature to also allow text after `*` wildcards in patterns. Previously the `*` was required to be at the end of the pattern. It lets you do something like this:
```json
{
"exports": {
"./features/*": "./features/*.js",
"./features/*.js": "./features/*.js"
}
}
```
With this release, esbuild now supports these types of patterns too.
- Fix subpath imports with Yarn PnP ([#2545](https://togithub.com/evanw/esbuild/issues/2545))
Node has a little-used feature called [subpath imports](https://nodejs.org/api/packages.html#subpath-imports) which are package-internal imports that start with `#` and that go through the `imports` map in `package.json`. Previously esbuild had a bug that caused esbuild to not handle these correctly in packages installed via Yarn's "Plug'n'Play" installation strategy. The problem was that subpath imports were being checked after Yarn PnP instead of before. This release reorders these checks, which should allow subpath imports to work in this case.
- Link from JS to CSS in the metafile ([#1861](https://togithub.com/evanw/esbuild/issues/1861), [#2565](https://togithub.com/evanw/esbuild/issues/2565))
When you import CSS into a bundled JS file, esbuild creates a parallel CSS bundle next to your JS bundle. So if `app.ts` imports some CSS files and you bundle it, esbuild will give you `app.js` and `app.css`. You would then add both `` and `` to your HTML to include everything in the page. This approach is more efficient than having esbuild insert additional JavaScript into `app.js` that downloads and includes `app.css` because it means the browser can download and parse both the CSS and the JS in parallel (and potentially apply the CSS before the JS has even finished downloading).
However, sometimes it's difficult to generate the `` tag. One case is when you've added `[hash]` to the [entry names](https://esbuild.github.io/api/#entry-names) setting to include a content hash in the file name. Then the file name will look something like `app-GX7G2SBE.css` and may change across subsequent builds. You can tell esbuild to generate build metadata using the `metafile` API option but the metadata only tells you which generated JS bundle corresponds to a JS entry point (via the `entryPoint` property), not which file corresponds to the associated CSS bundle. Working around this was hacky and involved string manipulation.
This release adds the `cssBundle` property to the metafile to make this easier. It's present on the metadata for the generated JS bundle and points to the associated CSS bundle. So to generate the HTML tags for a given JS entry point, you first find the output file with the `entryPoint` you are looking for (and put that in a ` Githubissues.
Githubissues is a development platform for aggregating issues.
This PR contains the following updates:
0.14.38->0.15.14Release Notes
evanw/esbuild
### [`v0.15.14`](https://togithub.com/evanw/esbuild/blob/HEAD/CHANGELOG.md#01514) [Compare Source](https://togithub.com/evanw/esbuild/compare/v0.15.13...v0.15.14) - Fix parsing of TypeScript `infer` inside a conditional `extends` ([#2675](https://togithub.com/evanw/esbuild/issues/2675)) Unlike JavaScript, parsing TypeScript sometimes requires backtracking. The `infer A` type operator can take an optional constraint of the form `infer A extends B`. However, this syntax conflicts with the similar conditional type operator `A extends B ? C : D` in cases where the syntax is combined, such as `infer A extends B ? C : D`. This is supposed to be parsed as `(infer A) extends B ? C : D`. Previously esbuild incorrectly parsed this as `(infer A extends B) ? C : D` instead, which is a parse error since the `?:` conditional operator requires the `extends` keyword as part of the conditional type. TypeScript disambiguates by speculatively parsing the `extends` after the `infer`, but backtracking if a `?` token is encountered afterward. With this release, esbuild should now do the same thing, so esbuild should now correctly parse these types. Here's a real-world example of such a type: ```ts type Normalized