evanw/esbuild
### [`v0.13.6`](https://togithub.com/evanw/esbuild/blob/master/CHANGELOG.md#0136)
[Compare Source](https://togithub.com/evanw/esbuild/compare/v0.13.5...v0.13.6)
- Emit decorators for `declare` class fields ([#1675](https://togithub.com/evanw/esbuild/issues/1675))
In version 3.7, TypeScript introduced the `declare` keyword for class fields that avoids generating any code for that field:
```ts
// TypeScript input
class Foo {
a: number
declare b: number
}
// JavaScript output
class Foo {
a;
}
```
However, it turns out that TypeScript still emits decorators for these omitted fields. With this release, esbuild will now do this too:
```ts
// TypeScript input
class Foo {
@decorator a: number;
@decorator declare b: number;
}
// Old JavaScript output
class Foo {
a;
}
__decorateClass([
decorator
], Foo.prototype, "a", 2);
// New JavaScript output
class Foo {
a;
}
__decorateClass([
decorator
], Foo.prototype, "a", 2);
__decorateClass([
decorator
], Foo.prototype, "b", 2);
```
- Experimental support for esbuild on NetBSD ([#1624](https://togithub.com/evanw/esbuild/pull/1624))
With this release, esbuild now has a published binary executable for [NetBSD](https://www.netbsd.org/) in the [`esbuild-netbsd-64`](https://www.npmjs.com/package/esbuild-netbsd-64) npm package, and esbuild's installer has been modified to attempt to use it when on NetBSD. Hopefully this makes installing esbuild via npm work on NetBSD. This change was contributed by [@gdt](https://togithub.com/gdt).
⚠️ Note: NetBSD is not one of [Node's supported platforms](https://nodejs.org/api/process.html#process_process_platform), so installing esbuild may or may not work on NetBSD depending on how Node has been patched. This is not a problem with esbuild. ⚠️
- Disable the "esbuild was bundled" warning if `ESBUILD_BINARY_PATH` is provided ([#1678](https://togithub.com/evanw/esbuild/pull/1678))
The `ESBUILD_BINARY_PATH` environment variable allows you to substitute an alternate binary executable for esbuild's JavaScript API. This is useful in certain cases such as when debugging esbuild. The JavaScript API has some code that throws an error if it detects that it was bundled before being run, since bundling prevents esbuild from being able to find the path to its binary executable. However, that error is unnecessary if `ESBUILD_BINARY_PATH` is present because an alternate path has been provided. This release disables the warning when `ESBUILD_BINARY_PATH` is present so that esbuild can be used when bundled as long as you also manually specify `ESBUILD_BINARY_PATH`.
This change was contributed by [@heypiotr](https://togithub.com/heypiotr).
- Remove unused `catch` bindings when minifying ([#1660](https://togithub.com/evanw/esbuild/pull/1660))
With this release, esbuild will now remove unused `catch` bindings when minifying:
```js
// Original code
try {
throw 0;
} catch (e) {
}
// Old output (with --minify)
try{throw 0}catch(t){}
// New output (with --minify)
try{throw 0}catch{}
```
This takes advantage of the new [optional catch binding](https://togithub.com/tc39/proposal-optional-catch-binding) syntax feature that was introduced in ES2019. This minification rule is only enabled when optional catch bindings are supported by the target environment. Specifically, it's not enabled when using `--target=es2018` or older. Make sure to set esbuild's `target` setting correctly when minifying if the code will be running in an older JavaScript environment.
This change was contributed by [@sapphi-red](https://togithub.com/sapphi-red).
### [`v0.13.5`](https://togithub.com/evanw/esbuild/blob/master/CHANGELOG.md#0135)
[Compare Source](https://togithub.com/evanw/esbuild/compare/v0.13.4...v0.13.5)
- Improve watch mode accuracy ([#1113](https://togithub.com/evanw/esbuild/issues/1113))
Watch mode is enabled by `--watch` and causes esbuild to become a long-running process that automatically rebuilds output files when input files are changed. It's implemented by recording all calls to esbuild's internal file system interface and then invalidating the build whenever these calls would return different values. For example, a call to esbuild's internal `ReadFile()` function is considered to be different if either the presence of the file has changed (e.g. the file didn't exist before but now exists) or the presence of the file stayed the same but the content of the file has changed.
Previously esbuild's watch mode operated at the `ReadFile()` and `ReadDirectory()` level. When esbuild checked whether a directory entry existed or not (e.g. whether a directory contains a `node_modules` subdirectory or a `package.json` file), it called `ReadDirectory()` which then caused the build to depend on that directory's set of entries. This meant the build would be invalidated even if a new unrelated entry was added or removed, since that still changes the set of entries. This is problematic when using esbuild in environments that constantly create and destroy temporary directory entries in your project directory. In that case, esbuild's watch mode would constantly rebuild as the directory was constantly considered to be dirty.
With this release, watch mode now operates at the `ReadFile()` and `ReadDirectory().Get()` level. So when esbuild checks whether a directory entry exists or not, the build should now only depend on the presence status for that one directory entry. This should avoid unnecessary rebuilds due to unrelated directory entries being added or removed. The log messages generated using `--watch` will now also mention the specific directory entry whose presence status was changed if a build is invalidated for this reason.
Note that this optimization does not apply to plugins using the `watchDirs` return value because those paths are only specified at the directory level and do not describe individual directory entries. You can use `watchFiles` or `watchDirs` on the individual entries inside the directory to get a similar effect instead.
- Disallow certain uses of `<` in `.mts` and `.cts` files
The upcoming version 4.5 of TypeScript is introducing the `.mts` and `.cts` extensions that turn into the `.mjs` and `.cjs` extensions when compiled. However, unlike the existing `.ts` and `.tsx` extensions, expressions that start with `<` are disallowed when they would be ambiguous depending on whether they are parsed in `.ts` or `.tsx` mode. The ambiguity is caused by the overlap between the syntax for JSX elements and the old deprecated syntax for type casts:
| Syntax | `.ts` | `.tsx` | `.mts`/`.cts` |
|-------------------------------|----------------------|------------------|----------------------|
| `y` | ✅ Type cast | 🚫 Syntax error | 🚫 Syntax error |
| `() => {}` | ✅ Arrow function | 🚫 Syntax error | 🚫 Syntax error |
| `y` | 🚫 Syntax error | ✅ JSX element | 🚫 Syntax error |
| `() => {}` | 🚫 Syntax error | ✅ JSX element | 🚫 Syntax error |
| `() => {}` | 🚫 Syntax error | ✅ JSX element | 🚫 Syntax error |
| `() => {}` | 🚫 Syntax error | ✅ JSX element | 🚫 Syntax error |
| `() => {}` | ✅ Arrow function | ✅ Arrow function | ✅ Arrow function |
| `() => {}` | ✅ Arrow function | ✅ Arrow function | ✅ Arrow function |
This release of esbuild introduces a syntax error for these ambiguous syntax constructs in `.mts` and `.cts` files to match the new behavior of the TypeScript compiler.
- Do not remove empty `@keyframes` rules ([#1665](https://togithub.com/evanw/esbuild/issues/1665))
CSS minification in esbuild automatically removes empty CSS rules, since they have no effect. However, empty `@keyframes` rules still trigger JavaScript animation events so it's incorrect to remove them. To demonstrate that empty `@keyframes` rules still have an effect, here is a bug report for Firefox where it was incorrectly not triggering JavaScript animation events for empty `@keyframes` rules: https://bugzilla.mozilla.org/show_bug.cgi?id=1004377.
With this release, empty `@keyframes` rules are now preserved during minification:
```css
/* Original CSS */
@keyframes foo {
from {}
to {}
}
/* Old output (with --minify) */
/* New output (with --minify) */
@keyframes foo{}
```
This fix was contributed by [@eelco](https://togithub.com/eelco).
- Fix an incorrect duplicate label error ([#1671](https://togithub.com/evanw/esbuild/pull/1671))
When labeling a statement in JavaScript, the label must be unique within the enclosing statements since the label determines the jump target of any labeled `break` or `continue` statement:
```js
// This code is valid
x: y: z: break x;
// This code is invalid
x: y: x: break x;
```
However, an enclosing label with the same name *is* allowed as long as it's located in a different function body. Since `break` and `continue` statements can't jump across function boundaries, the label is not ambiguous. This release fixes a bug where esbuild incorrectly treated this valid code as a syntax error:
```js
// This code is valid, but was incorrectly considered a syntax error
x: (() => {
x: break x;
})();
```
This fix was contributed by [@nevkontakte](https://togithub.com/nevkontakte).
Configuration
📅 Schedule: "every weekend" in timezone Asia/Tokyo.
🚦 Automerge: Enabled.
♻ 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 contains the following updates:
0.13.4->0.13.6Release Notes
evanw/esbuild
### [`v0.13.6`](https://togithub.com/evanw/esbuild/blob/master/CHANGELOG.md#0136) [Compare Source](https://togithub.com/evanw/esbuild/compare/v0.13.5...v0.13.6) - Emit decorators for `declare` class fields ([#1675](https://togithub.com/evanw/esbuild/issues/1675)) In version 3.7, TypeScript introduced the `declare` keyword for class fields that avoids generating any code for that field: ```ts // TypeScript input class Foo { a: number declare b: number } // JavaScript output class Foo { a; } ``` However, it turns out that TypeScript still emits decorators for these omitted fields. With this release, esbuild will now do this too: ```ts // TypeScript input class Foo { @decorator a: number; @decorator declare b: number; } // Old JavaScript output class Foo { a; } __decorateClass([ decorator ], Foo.prototype, "a", 2); // New JavaScript output class Foo { a; } __decorateClass([ decorator ], Foo.prototype, "a", 2); __decorateClass([ decorator ], Foo.prototype, "b", 2); ``` - Experimental support for esbuild on NetBSD ([#1624](https://togithub.com/evanw/esbuild/pull/1624)) With this release, esbuild now has a published binary executable for [NetBSD](https://www.netbsd.org/) in the [`esbuild-netbsd-64`](https://www.npmjs.com/package/esbuild-netbsd-64) npm package, and esbuild's installer has been modified to attempt to use it when on NetBSD. Hopefully this makes installing esbuild via npm work on NetBSD. This change was contributed by [@gdt](https://togithub.com/gdt). ⚠️ Note: NetBSD is not one of [Node's supported platforms](https://nodejs.org/api/process.html#process_process_platform), so installing esbuild may or may not work on NetBSD depending on how Node has been patched. This is not a problem with esbuild. ⚠️ - Disable the "esbuild was bundled" warning if `ESBUILD_BINARY_PATH` is provided ([#1678](https://togithub.com/evanw/esbuild/pull/1678)) The `ESBUILD_BINARY_PATH` environment variable allows you to substitute an alternate binary executable for esbuild's JavaScript API. This is useful in certain cases such as when debugging esbuild. The JavaScript API has some code that throws an error if it detects that it was bundled before being run, since bundling prevents esbuild from being able to find the path to its binary executable. However, that error is unnecessary if `ESBUILD_BINARY_PATH` is present because an alternate path has been provided. This release disables the warning when `ESBUILD_BINARY_PATH` is present so that esbuild can be used when bundled as long as you also manually specify `ESBUILD_BINARY_PATH`. This change was contributed by [@heypiotr](https://togithub.com/heypiotr). - Remove unused `catch` bindings when minifying ([#1660](https://togithub.com/evanw/esbuild/pull/1660)) With this release, esbuild will now remove unused `catch` bindings when minifying: ```js // Original code try { throw 0; } catch (e) { } // Old output (with --minify) try{throw 0}catch(t){} // New output (with --minify) try{throw 0}catch{} ``` This takes advantage of the new [optional catch binding](https://togithub.com/tc39/proposal-optional-catch-binding) syntax feature that was introduced in ES2019. This minification rule is only enabled when optional catch bindings are supported by the target environment. Specifically, it's not enabled when using `--target=es2018` or older. Make sure to set esbuild's `target` setting correctly when minifying if the code will be running in an older JavaScript environment. This change was contributed by [@sapphi-red](https://togithub.com/sapphi-red). ### [`v0.13.5`](https://togithub.com/evanw/esbuild/blob/master/CHANGELOG.md#0135) [Compare Source](https://togithub.com/evanw/esbuild/compare/v0.13.4...v0.13.5) - Improve watch mode accuracy ([#1113](https://togithub.com/evanw/esbuild/issues/1113)) Watch mode is enabled by `--watch` and causes esbuild to become a long-running process that automatically rebuilds output files when input files are changed. It's implemented by recording all calls to esbuild's internal file system interface and then invalidating the build whenever these calls would return different values. For example, a call to esbuild's internal `ReadFile()` function is considered to be different if either the presence of the file has changed (e.g. the file didn't exist before but now exists) or the presence of the file stayed the same but the content of the file has changed. Previously esbuild's watch mode operated at the `ReadFile()` and `ReadDirectory()` level. When esbuild checked whether a directory entry existed or not (e.g. whether a directory contains a `node_modules` subdirectory or a `package.json` file), it called `ReadDirectory()` which then caused the build to depend on that directory's set of entries. This meant the build would be invalidated even if a new unrelated entry was added or removed, since that still changes the set of entries. This is problematic when using esbuild in environments that constantly create and destroy temporary directory entries in your project directory. In that case, esbuild's watch mode would constantly rebuild as the directory was constantly considered to be dirty. With this release, watch mode now operates at the `ReadFile()` and `ReadDirectory().Get()` level. So when esbuild checks whether a directory entry exists or not, the build should now only depend on the presence status for that one directory entry. This should avoid unnecessary rebuilds due to unrelated directory entries being added or removed. The log messages generated using `--watch` will now also mention the specific directory entry whose presence status was changed if a build is invalidated for this reason. Note that this optimization does not apply to plugins using the `watchDirs` return value because those paths are only specified at the directory level and do not describe individual directory entries. You can use `watchFiles` or `watchDirs` on the individual entries inside the directory to get a similar effect instead. - Disallow certain uses of `<` in `.mts` and `.cts` files The upcoming version 4.5 of TypeScript is introducing the `.mts` and `.cts` extensions that turn into the `.mjs` and `.cjs` extensions when compiled. However, unlike the existing `.ts` and `.tsx` extensions, expressions that start with `<` are disallowed when they would be ambiguous depending on whether they are parsed in `.ts` or `.tsx` mode. The ambiguity is caused by the overlap between the syntax for JSX elements and the old deprecated syntax for type casts: | Syntax | `.ts` | `.tsx` | `.mts`/`.cts` | |-------------------------------|----------------------|------------------|----------------------| | `Configuration
📅 Schedule: "every weekend" in timezone Asia/Tokyo.
🚦 Automerge: Enabled.
♻ 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 WhiteSource Renovate. View repository job log here.