evanw/esbuild
### [`v0.14.23`](https://togithub.com/evanw/esbuild/blob/HEAD/CHANGELOG.md#01423)
[Compare Source](https://togithub.com/evanw/esbuild/compare/v0.14.22...v0.14.23)
- Update feature database to indicate that node 16.14+ supports import assertions ([#2030](https://togithub.com/evanw/esbuild/issues/2030))
Node versions 16.14 and above now support import assertions according to [these release notes](https://togithub.com/nodejs/node/blob/6db686710ee1579452b2908a7a41b91cb729b944/doc/changelogs/CHANGELOG_V16.md#16.14.0). This release updates esbuild's internal feature compatibility database with this information, so esbuild no longer strips import assertions with `--target=node16.14`:
```js
// Original code
import data from './package.json' assert { type: 'json' }
console.log(data)
// Old output (with --target=node16.14)
import data from "./package.json";
console.log(data);
// New output (with --target=node16.14)
import data from "./package.json" assert { type: "json" };
console.log(data);
```
- Basic support for CSS `@layer` rules ([#2027](https://togithub.com/evanw/esbuild/issues/2027))
This adds basic parsing support for a new CSS feature called `@layer` that changes how the CSS cascade works. Adding parsing support for this rule to esbuild means esbuild can now minify the contents of `@layer` rules:
```css
/* Original code */
@layer a {
@layer b {
div {
color: yellow;
margin: 0.0px;
}
}
}
/* Old output (with --minify) */
@layer a{@layer b {div {color: yellow; margin: 0px;}}}
/* New output (with --minify) */
@layer a.b{div{color:#ff0;margin:0}}
```
You can read more about `@layer` here:
- Documentation: https://developer.mozilla.org/en-US/docs/Web/CSS/[@layer](https://togithub.com/layer)
- Motivation: https://developer.chrome.com/blog/cascade-layers/
Note that the support added in this release is only for parsing and printing `@layer` rules. The bundler does not yet know about these rules and bundling with `@layer` may result in behavior changes since these new rules have unusual ordering constraints that behave differently than all other CSS rules. Specifically the order is derived from the *first* instance while with every other CSS rule, the order is derived from the *last* instance.
### [`v0.14.22`](https://togithub.com/evanw/esbuild/blob/HEAD/CHANGELOG.md#01422)
[Compare Source](https://togithub.com/evanw/esbuild/compare/v0.14.21...v0.14.22)
- Preserve whitespace for token lists that look like CSS variable declarations ([#2020](https://togithub.com/evanw/esbuild/issues/2020))
Previously esbuild removed the whitespace after the CSS variable declaration in the following CSS:
```css
/* Original input */
@supports (--foo: ){html{background:green}}
/* Previous output */
@supports (--foo:){html{background:green}}
```
However, that broke rendering in Chrome as it caused Chrome to ignore the entire rule. This did not break rendering in Firefox and Safari, so there's a browser bug either with Chrome or with both Firefox and Safari. In any case, esbuild now preserves whitespace after the CSS variable declaration in this case.
- Ignore legal comments when merging adjacent duplicate CSS rules ([#2016](https://togithub.com/evanw/esbuild/issues/2016))
This release now generates more compact minified CSS when there are legal comments in between two adjacent rules with identical content:
```css
/* Original code */
a { color: red }
/* @preserve */
b { color: red }
/* Old output (with --minify) */
a{color:red}/* @preserve */b{color:red}
/* New output (with --minify) */
a,b{color:red}/* @preserve */
```
- Block `onResolve` and `onLoad` until `onStart` ends ([#1967](https://togithub.com/evanw/esbuild/issues/1967))
This release changes the semantics of the `onStart` callback. All `onStart` callbacks from all plugins are run concurrently so that a slow plugin doesn't hold up the entire build. That's still the case. However, previously the only thing waiting for the `onStart` callbacks to finish was the end of the build. This meant that `onResolve` and/or `onLoad` callbacks could sometimes run before `onStart` had finished. This was by design but violated user expectations. With this release, all `onStart` callbacks must finish before any `onResolve` and/or `onLoad` callbacks are run.
- Add a self-referential `default` export to the JS API ([#1897](https://togithub.com/evanw/esbuild/issues/1897))
Some people try to use esbuild's API using `import esbuild from 'esbuild'` instead of `import * as esbuild from 'esbuild'` (i.e. using a default import instead of a namespace import). There is no `default` export so that wasn't ever intended to work. But it would work sometimes depending on which tools you used and how they were configured so some people still wrote code this way. This release tries to make that work by adding a self-referential `default` export that is equal to esbuild's module namespace object.
More detail: The published package for esbuild's JS API is in CommonJS format, although the source code for esbuild's JS API is in ESM format. The original ESM code for esbuild's JS API has no export named `default` so using a default import like this doesn't work with Babel-compatible toolchains (since they respect the semantics of the original ESM code). However, it happens to work with node-compatible toolchains because node's implementation of importing CommonJS from ESM broke compatibility with existing conventions and automatically creates a `default` export which is set to `module.exports`. This is an unfortunate compatibility headache because it means the `default` import only works sometimes. This release tries to fix this by explicitly creating a self-referential `default` export. It now doesn't matter if you do `esbuild.build()`, `esbuild.default.build()`, or `esbuild.default.default.build()` because they should all do the same thing. Hopefully this means people don't have to deal with this problem anymore.
- Handle `write` errors when esbuild's child process is killed ([#2007](https://togithub.com/evanw/esbuild/issues/2007))
If you type Ctrl+C in a terminal when a script that uses esbuild's JS library is running, esbuild's child process may be killed before the parent process. In that case calls to the `write()` syscall may fail with an `EPIPE` error. Previously this resulted in an uncaught exception because esbuild didn't handle this case. Starting with this release, esbuild should now catch these errors and redirect them into a general `The service was stopped` error which should be returned from whatever top-level API calls were in progress.
- Better error message when browser WASM bugs are present ([#1863](https://togithub.com/evanw/esbuild/issues/1863))
Safari's WebAssembly implementation appears to be broken somehow, at least when running esbuild. Sometimes this manifests as a stack overflow and sometimes as a Go panic. Previously a Go panic resulted in the error message `Can't find variable: fs` but this should now result in the Go panic being printed to the console. Using esbuild's WebAssembly library in Safari is still broken but now there's a more helpful error message.
More detail: When Go panics, it prints a stack trace to stderr (i.e. file descriptor 2). Go's WebAssembly shim calls out to node's `fs.writeSync()` function to do this, and it converts calls to `fs.writeSync()` into calls to `console.log()` in the browser by providing a shim for `fs`. However, Go's shim code stores the shim on `window.fs` in the browser. This is undesirable because it pollutes the global scope and leads to brittle code that can break if other code also uses `window.fs`. To avoid this, esbuild shadows the global object by wrapping Go's shim. But that broke bare references to `fs` since the shim is no longer stored on `window.fs`. This release now stores the shim in a local variable named `fs` so that bare references to `fs` work correctly.
- Undo incorrect dead-code elimination with destructuring ([#1183](https://togithub.com/evanw/esbuild/issues/1183))
Previously esbuild eliminated these statements as dead code if tree-shaking was enabled:
```js
let [a] = {}
let { b } = null
```
This is incorrect because both of these lines will throw an error when evaluated. With this release, esbuild now preserves these statements even when tree shaking is enabled.
- Update to Go 1.17.7
The version of the Go compiler used to compile esbuild has been upgraded from Go 1.17.6 to Go 1.17.7, which contains a few [compiler and security bug fixes](https://togithub.com/golang/go/issues?q=milestone%3AGo1.17.7+label%3ACherryPickApproved).
### [`v0.14.21`](https://togithub.com/evanw/esbuild/blob/HEAD/CHANGELOG.md#01421)
[Compare Source](https://togithub.com/evanw/esbuild/compare/v0.14.20...v0.14.21)
- Handle an additional `browser` map edge case ([#2001](https://togithub.com/evanw/esbuild/pull/2001), [#2002](https://togithub.com/evanw/esbuild/issues/2002))
There is a community convention around the `browser` field in `package.json` that allows remapping import paths within a package when the package is bundled for use within a browser. There isn't a rigorous definition of how it's supposed to work and every bundler implements it differently. The approach esbuild uses is to try to be "maximally compatible" in that if at least one bundler exhibits a particular behavior regarding the `browser` map that allows a mapping to work, then esbuild also attempts to make that work.
I have a collection of test cases for this going here: https://github.com/evanw/package-json-browser-tests. However, I was missing test coverage for the edge case where a package path import in a subdirectory of the package could potentially match a remapping. The "maximally compatible" approach means replicating bugs in Browserify's implementation of the feature where package paths are mistaken for relative paths and are still remapped. Here's a specific example of an edge case that's now handled:
- `entry.js`:
```js
require('pkg/sub')
```
- `node_modules/pkg/package.json`:
```json
{
"browser": {
"./sub": "./sub/foo.js",
"./sub/sub": "./sub/bar.js"
}
}
```
- `node_modules/pkg/sub/foo.js`:
```js
require('sub')
```
- `node_modules/pkg/sub/bar.js`:
```js
console.log('works')
```
The import path `sub` in `require('sub')` is mistaken for a relative path by Browserify due to a bug in Browserify, so Browserify treats it as if it were `./sub` instead. This is a Browserify-specific behavior and currently doesn't happen in any other bundler (except for esbuild, which attempts to replicate Browserify's bug).
Previously esbuild was incorrectly resolving `./sub` relative to the top-level package directory instead of to the subdirectory in this case, which meant `./sub` was incorrectly matching `"./sub": "./sub/foo.js"` instead of `"./sub/sub": "./sub/bar.js"`. This has been fixed so esbuild can now emulate Browserify's bug correctly in this edge case.
- Support for esbuild with Linux on RISC-V 64bit ([#2000](https://togithub.com/evanw/esbuild/pull/2000))
With this release, esbuild now has a published binary executable for the RISC-V 64bit architecture in the [`esbuild-linux-riscv64`](https://www.npmjs.com/package/esbuild-linux-riscv64) npm package. This change was contributed by [@piggynl](https://togithub.com/piggynl).
### [`v0.14.20`](https://togithub.com/evanw/esbuild/blob/HEAD/CHANGELOG.md#01420)
[Compare Source](https://togithub.com/evanw/esbuild/compare/v0.14.19...v0.14.20)
- Fix property mangling and keyword properties ([#1998](https://togithub.com/evanw/esbuild/issues/1998))
Previously enabling property mangling with `--mangle-props=` failed to add a space before property names after a keyword. This bug has been fixed:
```js
// Original code
class Foo {
static foo = {
get bar() {}
}
}
// Old output (with --minify --mangle-props=.)
class Foo{statics={gett(){}}}
// New output (with --minify --mangle-props=.)
class Foo{static s={get t(){}}}
```
### [`v0.14.19`](https://togithub.com/evanw/esbuild/blob/HEAD/CHANGELOG.md#01419)
[Compare Source](https://togithub.com/evanw/esbuild/compare/v0.14.18...v0.14.19)
- Special-case `const` inlining at the top of a scope ([#1317](https://togithub.com/evanw/esbuild/issues/1317), [#1981](https://togithub.com/evanw/esbuild/issues/1981))
The minifier now inlines `const` variables (even across modules during bundling) if a certain set of specific requirements are met:
- All `const` variables to be inlined are at the top of their scope
- That scope doesn't contain any `import` or `export` statements with paths
- All constants to be inlined are `null`, `undefined`, `true`, `false`, an integer, or a short real number
- Any expression outside of a small list of allowed ones stops constant identification
Practically speaking this basically means that you can trigger this optimization by just putting the constants you want inlined into a separate file (e.g. `constants.js`) and bundling everything together.
These specific conditions are present to avoid esbuild unintentionally causing any behavior changes by inlining constants when the variable reference could potentially be evaluated before being declared. It's possible to identify more cases where constants can be inlined but doing so may require complex call graph analysis so it has not been implemented. Although these specific heuristics may change over time, this general approach to constant inlining should continue to work going forward.
Here's an example:
```js
// Original code
const bold = 1 << 0;
const italic = 1 << 1;
const underline = 1 << 2;
const font = bold | italic | underline;
console.log(font);
// Old output (with --minify --bundle)
(()=>{var o=1<<0,n=1<<1,c=1<<2,t=o|n|c;console.log(t);})();
// New output (with --minify --bundle)
(()=>{console.log(7);})();
```
### [`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.
Configuration
📅 Schedule: "on the first day of the month" (UTC).
🚦 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 contains the following updates:
0.14.16->0.14.23Release Notes
evanw/esbuild
### [`v0.14.23`](https://togithub.com/evanw/esbuild/blob/HEAD/CHANGELOG.md#01423) [Compare Source](https://togithub.com/evanw/esbuild/compare/v0.14.22...v0.14.23) - Update feature database to indicate that node 16.14+ supports import assertions ([#2030](https://togithub.com/evanw/esbuild/issues/2030)) Node versions 16.14 and above now support import assertions according to [these release notes](https://togithub.com/nodejs/node/blob/6db686710ee1579452b2908a7a41b91cb729b944/doc/changelogs/CHANGELOG_V16.md#16.14.0). This release updates esbuild's internal feature compatibility database with this information, so esbuild no longer strips import assertions with `--target=node16.14`: ```js // Original code import data from './package.json' assert { type: 'json' } console.log(data) // Old output (with --target=node16.14) import data from "./package.json"; console.log(data); // New output (with --target=node16.14) import data from "./package.json" assert { type: "json" }; console.log(data); ``` - Basic support for CSS `@layer` rules ([#2027](https://togithub.com/evanw/esbuild/issues/2027)) This adds basic parsing support for a new CSS feature called `@layer` that changes how the CSS cascade works. Adding parsing support for this rule to esbuild means esbuild can now minify the contents of `@layer` rules: ```css /* Original code */ @layer a { @layer b { div { color: yellow; margin: 0.0px; } } } /* Old output (with --minify) */ @layer a{@layer b {div {color: yellow; margin: 0px;}}} /* New output (with --minify) */ @layer a.b{div{color:#ff0;margin:0}} ``` You can read more about `@layer` here: - Documentation: https://developer.mozilla.org/en-US/docs/Web/CSS/[@layer](https://togithub.com/layer) - Motivation: https://developer.chrome.com/blog/cascade-layers/ Note that the support added in this release is only for parsing and printing `@layer` rules. The bundler does not yet know about these rules and bundling with `@layer` may result in behavior changes since these new rules have unusual ordering constraints that behave differently than all other CSS rules. Specifically the order is derived from the *first* instance while with every other CSS rule, the order is derived from the *last* instance. ### [`v0.14.22`](https://togithub.com/evanw/esbuild/blob/HEAD/CHANGELOG.md#01422) [Compare Source](https://togithub.com/evanw/esbuild/compare/v0.14.21...v0.14.22) - Preserve whitespace for token lists that look like CSS variable declarations ([#2020](https://togithub.com/evanw/esbuild/issues/2020)) Previously esbuild removed the whitespace after the CSS variable declaration in the following CSS: ```css /* Original input */ @supports (--foo: ){html{background:green}} /* Previous output */ @supports (--foo:){html{background:green}} ``` However, that broke rendering in Chrome as it caused Chrome to ignore the entire rule. This did not break rendering in Firefox and Safari, so there's a browser bug either with Chrome or with both Firefox and Safari. In any case, esbuild now preserves whitespace after the CSS variable declaration in this case. - Ignore legal comments when merging adjacent duplicate CSS rules ([#2016](https://togithub.com/evanw/esbuild/issues/2016)) This release now generates more compact minified CSS when there are legal comments in between two adjacent rules with identical content: ```css /* Original code */ a { color: red } /* @preserve */ b { color: red } /* Old output (with --minify) */ a{color:red}/* @preserve */b{color:red} /* New output (with --minify) */ a,b{color:red}/* @preserve */ ``` - Block `onResolve` and `onLoad` until `onStart` ends ([#1967](https://togithub.com/evanw/esbuild/issues/1967)) This release changes the semantics of the `onStart` callback. All `onStart` callbacks from all plugins are run concurrently so that a slow plugin doesn't hold up the entire build. That's still the case. However, previously the only thing waiting for the `onStart` callbacks to finish was the end of the build. This meant that `onResolve` and/or `onLoad` callbacks could sometimes run before `onStart` had finished. This was by design but violated user expectations. With this release, all `onStart` callbacks must finish before any `onResolve` and/or `onLoad` callbacks are run. - Add a self-referential `default` export to the JS API ([#1897](https://togithub.com/evanw/esbuild/issues/1897)) Some people try to use esbuild's API using `import esbuild from 'esbuild'` instead of `import * as esbuild from 'esbuild'` (i.e. using a default import instead of a namespace import). There is no `default` export so that wasn't ever intended to work. But it would work sometimes depending on which tools you used and how they were configured so some people still wrote code this way. This release tries to make that work by adding a self-referential `default` export that is equal to esbuild's module namespace object. More detail: The published package for esbuild's JS API is in CommonJS format, although the source code for esbuild's JS API is in ESM format. The original ESM code for esbuild's JS API has no export named `default` so using a default import like this doesn't work with Babel-compatible toolchains (since they respect the semantics of the original ESM code). However, it happens to work with node-compatible toolchains because node's implementation of importing CommonJS from ESM broke compatibility with existing conventions and automatically creates a `default` export which is set to `module.exports`. This is an unfortunate compatibility headache because it means the `default` import only works sometimes. This release tries to fix this by explicitly creating a self-referential `default` export. It now doesn't matter if you do `esbuild.build()`, `esbuild.default.build()`, or `esbuild.default.default.build()` because they should all do the same thing. Hopefully this means people don't have to deal with this problem anymore. - Handle `write` errors when esbuild's child process is killed ([#2007](https://togithub.com/evanw/esbuild/issues/2007)) If you type Ctrl+C in a terminal when a script that uses esbuild's JS library is running, esbuild's child process may be killed before the parent process. In that case calls to the `write()` syscall may fail with an `EPIPE` error. Previously this resulted in an uncaught exception because esbuild didn't handle this case. Starting with this release, esbuild should now catch these errors and redirect them into a general `The service was stopped` error which should be returned from whatever top-level API calls were in progress. - Better error message when browser WASM bugs are present ([#1863](https://togithub.com/evanw/esbuild/issues/1863)) Safari's WebAssembly implementation appears to be broken somehow, at least when running esbuild. Sometimes this manifests as a stack overflow and sometimes as a Go panic. Previously a Go panic resulted in the error message `Can't find variable: fs` but this should now result in the Go panic being printed to the console. Using esbuild's WebAssembly library in Safari is still broken but now there's a more helpful error message. More detail: When Go panics, it prints a stack trace to stderr (i.e. file descriptor 2). Go's WebAssembly shim calls out to node's `fs.writeSync()` function to do this, and it converts calls to `fs.writeSync()` into calls to `console.log()` in the browser by providing a shim for `fs`. However, Go's shim code stores the shim on `window.fs` in the browser. This is undesirable because it pollutes the global scope and leads to brittle code that can break if other code also uses `window.fs`. To avoid this, esbuild shadows the global object by wrapping Go's shim. But that broke bare references to `fs` since the shim is no longer stored on `window.fs`. This release now stores the shim in a local variable named `fs` so that bare references to `fs` work correctly. - Undo incorrect dead-code elimination with destructuring ([#1183](https://togithub.com/evanw/esbuild/issues/1183)) Previously esbuild eliminated these statements as dead code if tree-shaking was enabled: ```js let [a] = {} let { b } = null ``` This is incorrect because both of these lines will throw an error when evaluated. With this release, esbuild now preserves these statements even when tree shaking is enabled. - Update to Go 1.17.7 The version of the Go compiler used to compile esbuild has been upgraded from Go 1.17.6 to Go 1.17.7, which contains a few [compiler and security bug fixes](https://togithub.com/golang/go/issues?q=milestone%3AGo1.17.7+label%3ACherryPickApproved). ### [`v0.14.21`](https://togithub.com/evanw/esbuild/blob/HEAD/CHANGELOG.md#01421) [Compare Source](https://togithub.com/evanw/esbuild/compare/v0.14.20...v0.14.21) - Handle an additional `browser` map edge case ([#2001](https://togithub.com/evanw/esbuild/pull/2001), [#2002](https://togithub.com/evanw/esbuild/issues/2002)) There is a community convention around the `browser` field in `package.json` that allows remapping import paths within a package when the package is bundled for use within a browser. There isn't a rigorous definition of how it's supposed to work and every bundler implements it differently. The approach esbuild uses is to try to be "maximally compatible" in that if at least one bundler exhibits a particular behavior regarding the `browser` map that allows a mapping to work, then esbuild also attempts to make that work. I have a collection of test cases for this going here: https://github.com/evanw/package-json-browser-tests. However, I was missing test coverage for the edge case where a package path import in a subdirectory of the package could potentially match a remapping. The "maximally compatible" approach means replicating bugs in Browserify's implementation of the feature where package paths are mistaken for relative paths and are still remapped. Here's a specific example of an edge case that's now handled: - `entry.js`: ```js require('pkg/sub') ``` - `node_modules/pkg/package.json`: ```json { "browser": { "./sub": "./sub/foo.js", "./sub/sub": "./sub/bar.js" } } ``` - `node_modules/pkg/sub/foo.js`: ```js require('sub') ``` - `node_modules/pkg/sub/bar.js`: ```js console.log('works') ``` The import path `sub` in `require('sub')` is mistaken for a relative path by Browserify due to a bug in Browserify, so Browserify treats it as if it were `./sub` instead. This is a Browserify-specific behavior and currently doesn't happen in any other bundler (except for esbuild, which attempts to replicate Browserify's bug). Previously esbuild was incorrectly resolving `./sub` relative to the top-level package directory instead of to the subdirectory in this case, which meant `./sub` was incorrectly matching `"./sub": "./sub/foo.js"` instead of `"./sub/sub": "./sub/bar.js"`. This has been fixed so esbuild can now emulate Browserify's bug correctly in this edge case. - Support for esbuild with Linux on RISC-V 64bit ([#2000](https://togithub.com/evanw/esbuild/pull/2000)) With this release, esbuild now has a published binary executable for the RISC-V 64bit architecture in the [`esbuild-linux-riscv64`](https://www.npmjs.com/package/esbuild-linux-riscv64) npm package. This change was contributed by [@piggynl](https://togithub.com/piggynl). ### [`v0.14.20`](https://togithub.com/evanw/esbuild/blob/HEAD/CHANGELOG.md#01420) [Compare Source](https://togithub.com/evanw/esbuild/compare/v0.14.19...v0.14.20) - Fix property mangling and keyword properties ([#1998](https://togithub.com/evanw/esbuild/issues/1998)) Previously enabling property mangling with `--mangle-props=` failed to add a space before property names after a keyword. This bug has been fixed: ```js // Original code class Foo { static foo = { get bar() {} } } // Old output (with --minify --mangle-props=.) class Foo{statics={gett(){}}} // New output (with --minify --mangle-props=.) class Foo{static s={get t(){}}} ``` ### [`v0.14.19`](https://togithub.com/evanw/esbuild/blob/HEAD/CHANGELOG.md#01419) [Compare Source](https://togithub.com/evanw/esbuild/compare/v0.14.18...v0.14.19) - Special-case `const` inlining at the top of a scope ([#1317](https://togithub.com/evanw/esbuild/issues/1317), [#1981](https://togithub.com/evanw/esbuild/issues/1981)) The minifier now inlines `const` variables (even across modules during bundling) if a certain set of specific requirements are met: - All `const` variables to be inlined are at the top of their scope - That scope doesn't contain any `import` or `export` statements with paths - All constants to be inlined are `null`, `undefined`, `true`, `false`, an integer, or a short real number - Any expression outside of a small list of allowed ones stops constant identification Practically speaking this basically means that you can trigger this optimization by just putting the constants you want inlined into a separate file (e.g. `constants.js`) and bundling everything together. These specific conditions are present to avoid esbuild unintentionally causing any behavior changes by inlining constants when the variable reference could potentially be evaluated before being declared. It's possible to identify more cases where constants can be inlined but doing so may require complex call graph analysis so it has not been implemented. Although these specific heuristics may change over time, this general approach to constant inlining should continue to work going forward. Here's an example: ```js // Original code const bold = 1 << 0; const italic = 1 << 1; const underline = 1 << 2; const font = bold | italic | underline; console.log(font); // Old output (with --minify --bundle) (()=>{var o=1<<0,n=1<<1,c=1<<2,t=o|n|c;console.log(t);})(); // New output (with --minify --bundle) (()=>{console.log(7);})(); ``` ### [`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.Configuration
📅 Schedule: "on the first day of the month" (UTC).
🚦 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 WhiteSource Renovate. View repository job log here.