evanw/esbuild
### [`v0.14.1`](https://togithub.com/evanw/esbuild/blob/master/CHANGELOG.md#0141)
[Compare Source](https://togithub.com/evanw/esbuild/compare/v0.14.0...v0.14.1)
- Fix `imports` in `package.json` ([#1807](https://togithub.com/evanw/esbuild/issues/1807))
This release contains a fix for the rarely-used [`imports` feature in `package.json` files](https://nodejs.org/api/packages.html#subpath-imports) that lets a package specify a custom remapping for import paths inside that package that start with `#`. Support for `imports` was added in version 0.13.9. However, the field was being incorrectly interpreted as relative to the importing file instead of to the `package.json` file, which caused an import failure when the importing file is in a subdirectory instead of being at the top level of the package. Import paths should now be interpreted as relative to the correct directory which should fix these path resolution failures.
- Isolate implicit sibling scope lookup for `enum` and `namespace`
The previous release implemented sibling namespaces in TypeScript, which introduces a new kind of scope lookup that doesn't exist in JavaScript. Exported members inside an `enum` or `namespace` block can be implicitly referenced in a sibling `enum` or `namespace` block just by using the name without using a property reference. However, this behavior appears to only work for `enum`-to-`enum` and `namespace`-to-`namespace` interactions. Even though sibling enums and namespaces with the same name can be merged together into the same underlying object, this implicit reference behavior doesn't work for `enum`-to-`namespace` interactions and attempting to do this with a `namespace`-to-`enum` interaction [causes the TypeScript compiler itself to crash](https://togithub.com/microsoft/TypeScript/issues/46891). Here is an example of how the TypeScript compiler behaves in each case:
```ts
// "b" is accessible
enum a { b = 1 }
enum a { c = b }
// "e" is accessible
namespace d { export let e = 1 }
namespace d { export let f = e }
// "h" is inaccessible
enum g { h = 1 }
namespace g { export let i = h }
// This causes the TypeScript compiler to crash
namespace j { export let k = 1 }
enum j { l = k }
```
This release changes the implicit sibling scope lookup behavior to only work for `enum`-to-`enum` and `namespace`-to-`namespace` interactions. These implicit references no longer work with `enum`-to-`namespace` and `namespace`-to-`enum` interactions, which should more accurately match the behavior of the TypeScript compiler.
- Add semicolon insertion before TypeScript-specific definite assignment assertion modifier ([#1810](https://togithub.com/evanw/esbuild/issues/1810))
TypeScript lets you add a `!` after a variable declaration to bypass TypeScript's definite assignment analysis:
```ts
let x!: number[];
initialize();
x.push(4);
function initialize() { x = [0, 1, 2, 3]; }
```
This `!` is called a [definite assignment assertion](https://devblogs.microsoft.com/typescript/announcing-typescript-2-7/#definite-assignment-assertions) and tells TypeScript to assume that the variable has been initialized somehow. However, JavaScript's automatic semicolon insertion rules should be able to insert a semicolon before it:
```ts
let a
!function(){}()
```
Previously the above code was incorrectly considered a syntax error in TypeScript. With this release, this code is now parsed correctly.
- Log output to stderr has been overhauled
This release changes the way log messages are formatted to stderr. The changes make the kind of message (e.g. error vs. warning vs. note) more obvious, and they also give more room for paragraph-style notes that can provide more detail about the message. Here's an example:
Before:
> example.tsx:14:25: warning: Comparison with -0 using the "===" operator will also match 0
14 │ case 1: return x === -0
╵ ~~
> example.tsx:21:23: error: Could not resolve "path" (use "--platform=node" when building for node)
21 │ const path = require('path')
╵ ~~~~~~
After:
▲ [WARNING] Comparison with -0 using the "===" operator will also match 0
example.tsx:14:25:
14 │ case 1: return x === -0
╵ ~~
Floating-point equality is defined such that 0 and -0 are equal, so "x === -0" returns true for
both 0 and -0. You need to use "Object.is(x, -0)" instead to test for -0.
✘ [ERROR] Could not resolve "path"
example.tsx:21:23:
21 │ const path = require('path')
╵ ~~~~~~
The package "path" wasn't found on the file system but is built into node. Are you trying to
bundle for node? You can use "--platform=node" to do that, which will remove this error.
Note that esbuild's formatted log output is for humans, not for machines. If you need to output a stable machine-readable format, you should be using the API for that. Build and transform results have arrays called `errors` and `warnings` with objects that represent the log messages.
- Show inlined enum value names in comments
When esbuild inlines an enum, it will now put a comment next to it with the original enum name:
```ts
// Original code
const enum Foo { FOO }
console.log(Foo.FOO)
// Old output
console.log(0);
// New output
console.log(0 /* FOO */);
```
This matches the behavior of the TypeScript compiler, and should help with debugging. These comments are not generated if minification is enabled.
### [`v0.14.0`](https://togithub.com/evanw/esbuild/blob/master/CHANGELOG.md#0140)
[Compare Source](https://togithub.com/evanw/esbuild/compare/v0.13.15...v0.14.0)
**This release contains backwards-incompatible changes.** Since esbuild is before version 1.0.0, these changes have been released as a new minor version to reflect this (as [recommended by npm](https://docs.npmjs.com/cli/v6/using-npm/semver/)). You should either be pinning the exact version of `esbuild` in your `package.json` file or be using a version range syntax that only accepts patch upgrades such as `~0.13.0`. See the documentation about [semver](https://docs.npmjs.com/cli/v6/using-npm/semver/) for more information.
- Add support for TypeScript's `preserveValueImports` setting ([#1525](https://togithub.com/evanw/esbuild/issues/1525))
TypeScript 4.5, which was just released, added [a new setting called `preserveValueImports`](https://devblogs.microsoft.com/typescript/announcing-typescript-4-5/#preserve-value-imports). This release of esbuild implements support for this new setting. However, this release also changes esbuild's behavior regarding the `importsNotUsedAsValues` setting, so this release is being considered a breaking change. Now esbuild's behavior should more accurately match the behavior of the TypeScript compiler. This is described in more detail below.
The difference in behavior is around unused imports. By default, unused import names are considered to be types and are completely removed if they are unused. If all import names are removed for a given import statement, then the whole import statement is removed too. The two `tsconfig.json` settings [`importsNotUsedAsValues`](https://www.typescriptlang.org/tsconfig#importsNotUsedAsValues) and [`preserveValueImports`](https://www.typescriptlang.org/tsconfig#preserveValueImports) let you customize this. Here's what the TypeScript compiler's output looks like with these different settings enabled:
```ts
// Original code
import { unused } from "foo";
// Default output
/* (the import is completely removed) */
// Output with "importsNotUsedAsValues": "preserve"
import "foo";
// Output with "preserveValueImports": true
import { unused } from "foo";
```
Previously, since the `preserveValueImports` setting didn't exist yet, esbuild had treated the `importsNotUsedAsValues` setting as if it were what is now the `preserveValueImports` setting instead. This was a deliberate deviation from how the TypeScript compiler behaves, but was necessary to allow esbuild to be used as a TypeScript-to-JavaScript compiler inside of certain composite languages such as Svelte and Vue. These languages append additional code after converting the TypeScript to JavaScript so unused imports may actually turn out to be used later on:
```svelte
```
Previously the implementers of these languages had to use the `importsNotUsedAsValues` setting as a hack for esbuild to preserve the import statements. With this release, esbuild now follows the behavior of the TypeScript compiler so implementers will need to use the new `preserveValueImports` setting to do this instead. This is the breaking change.
- TypeScript code follows JavaScript class field semantics with `--target=esnext` ([#1480](https://togithub.com/evanw/esbuild/issues/1480))
TypeScript 4.3 included a subtle breaking change that wasn't mentioned in the [TypeScript 4.3 blog post](https://devblogs.microsoft.com/typescript/announcing-typescript-4-3/): class fields will now be compiled with different semantics if `"target": "ESNext"` is present in `tsconfig.json`. Specifically in this case `useDefineForClassFields` will default to `true` when not specified instead of `false`. This means class field behavior in TypeScript code will now match JavaScript instead of doing something else:
```js
class Base {
set foo(value) { console.log('set', value) }
}
class Derived extends Base {
foo = 123
}
new Derived()
```
In TypeScript 4.2 and below, the TypeScript compiler would generate code that prints `set 123` when `tsconfig.json` contains `"target": "ESNext"` but in TypeScript 4.3 and above, the TypeScript compiler will now generate code that doesn't print anything. This is the difference between "assign" semantics and "define" semantics.
Previously you had to create a `tsconfig.json` file and specify `"target": "ESNext"` to get this behavior in esbuild. With this release, you can now also just pass `--target=esnext` to esbuild to force-enable this behavior. Note that esbuild doesn't do this by default even though the default value of `--target=` otherwise behaves like `esnext`. Since TypeScript's compiler doesn't do this behavior by default, it seems like a good idea for esbuild to not do this behavior by default either.
In addition to the breaking changes above, the following changes are also included in this release:
- Allow certain keywords as tuple type labels in TypeScript ([#1797](https://togithub.com/evanw/esbuild/issues/1797))
Apparently TypeScript lets you use certain keywords as tuple labels but not others. For example, `type x = [function: number]` is allowed while `type x = [class: number]` isn't. This release replicates this behavior in esbuild's TypeScript parser:
- Allowed keywords: `false`, `function`, `import`, `new`, `null`, `this`, `true`, `typeof`, `void`
- Forbidden keywords: `break`, `case`, `catch`, `class`, `const`, `continue`, `debugger`, `default`, `delete`, `do`, `else`, `enum`, `export`, `extends`, `finally`, `for`, `if`, `in`, `instanceof`, `return`, `super`, `switch`, `throw`, `try`, `var`, `while`, `with`
- Support sibling namespaces in TypeScript ([#1410](https://togithub.com/evanw/esbuild/issues/1410))
TypeScript has a feature where sibling namespaces with the same name can implicitly reference each other's exports without an explicit property access. This goes against how scope lookup works in JavaScript, so it previously didn't work with esbuild. This release adds support for this feature:
```ts
// Original TypeScript code
namespace x {
export let y = 123
}
namespace x {
export let z = y
}
// Old JavaScript output
var x;
(function(x2) {
x2.y = 123;
})(x || (x = {}));
(function(x2) {
x2.z = y;
})(x || (x = {}));
// New JavaScript output
var x;
(function(x2) {
x2.y = 123;
})(x || (x = {}));
(function(x2) {
x2.z = x2.y;
})(x || (x = {}));
```
Notice how the identifier `y` is now compiled to the property access `x2.y` which references the export named `y` on the namespace, instead of being left as the identifier `y` which references the global named `y`. This matches how the TypeScript compiler treats namespace objects. This new behavior also works for enums:
```ts
// Original TypeScript code
enum x {
y = 123
}
enum x {
z = y + 1
}
// Old JavaScript output
var x;
(function(x2) {
x2[x2["y"] = 123] = "y";
})(x || (x = {}));
(function(x2) {
x2[x2["z"] = y + 1] = "z";
})(x || (x = {}));
// New JavaScript output
var x;
(function(x2) {
x2[x2["y"] = 123] = "y";
})(x || (x = {}));
(function(x2) {
x2[x2["z"] = 124] = "z";
})(x || (x = {}));
```
Note that this behavior does **not** work across files. Each file is still compiled independently so the namespaces in each file are still resolved independently per-file. Implicit namespace cross-references still do not work across files. Getting this to work is counter to esbuild's parallel architecture and does not fit in with esbuild's design. It also doesn't make sense with esbuild's bundling model where input files are either in ESM or CommonJS format and therefore each have their own scope.
- Change output for top-level TypeScript enums
The output format for top-level TypeScript enums has been changed to reduce code size and improve tree shaking, which means that esbuild's enum output is now somewhat different than TypeScript's enum output. The behavior of both output formats should still be equivalent though. Here's an example that shows the difference:
```ts
// Original code
enum x {
y = 1,
z = 2
}
// Old output
var x;
(function(x2) {
x2[x2["y"] = 1] = "y";
x2[x2["z"] = 2] = "z";
})(x || (x = {}));
// New output
var x = /* @__PURE__ */ ((x2) => {
x2[x2["y"] = 1] = "y";
x2[x2["z"] = 2] = "z";
return x2;
})(x || {});
```
The function expression has been changed to an arrow expression to reduce code size and the enum initializer has been moved into the variable declaration to make it possible to be marked as `/* @__PURE__ */` to improve tree shaking. The `/* @__PURE__ */` annotation is now automatically added when all of the enum values are side-effect free, which means the entire enum definition can be removed as dead code if it's never referenced. Direct enum value references within the same file that have been inlined do not count as references to the enum definition so this should eliminate enums from the output in many cases:
```ts
// Original code
enum Foo { FOO = 1 }
enum Bar { BAR = 2 }
console.log(Foo, Bar.BAR)
// Old output (with --bundle --minify)
var n;(function(e){e[e.FOO=1]="FOO"})(n||(n={}));var l;(function(e){e[e.BAR=2]="BAR"})(l||(l={}));console.log(n,2);
// New output (with --bundle --minify)
var n=(e=>(e[e.FOO=1]="FOO",e))(n||{});console.log(n,2);
```
Notice how the new output is much shorter because the entire definition for `Bar` has been completely removed as dead code by esbuild's tree shaking.
The output may seem strange since it would be simpler to just have a plain object literal as an initializer. However, TypeScript's enum feature behaves similarly to TypeScript's namespace feature which means enums can merge with existing enums and/or existing namespaces (and in some cases also existing objects) if the existing definition has the same name. This new output format keeps its similarity to the original output format so that it still handles all of the various edge cases that TypeScript's enum feature supports. Initializing the enum using a plain object literal would not merge with existing definitions and would break TypeScript's enum semantics.
- Fix legal comment parsing in CSS ([#1796](https://togithub.com/evanw/esbuild/issues/1796))
Legal comments in CSS either start with `/*!` or contain `@preserve` or `@license` and are preserved by esbuild in the generated CSS output. This release fixes a bug where non-top-level legal comments inside a CSS file caused esbuild to skip any following legal comments even if those following comments are top-level:
```css
/* Original code */
.example {
--some-var: var(--tw-empty, /*!*/ /*!*/);
}
/*! Some legal comment */
body {
background-color: red;
}
/* Old output (with --minify) */
.example{--some-var: var(--tw-empty, )}body{background-color:red}
/* New output (with --minify) */
.example{--some-var: var(--tw-empty, )}/*! Some legal comment */body{background-color:red}
```
- Fix panic when printing invalid CSS ([#1803](https://togithub.com/evanw/esbuild/issues/1803))
This release fixes a panic caused by a conditional CSS `@import` rule with a URL token. Code like this caused esbuild to enter an unexpected state because the case where tokens in the import condition with associated import records wasn't handled. This case is now handled correctly:
```css
@import "example.css" url(foo);
```
- Mark `Set` and `Map` with array arguments as pure ([#1791](https://togithub.com/evanw/esbuild/issues/1791))
This release introduces special behavior for references to the global `Set` and `Map` constructors that marks them as `/* @__PURE__ */` if they are known to not have any side effects. These constructors evaluate the iterator of whatever is passed to them and the iterator could have side effects, so this is only safe if whatever is passed to them is an array, since the array iterator has no side effects.
Marking a constructor call as `/* @__PURE__ */` means it's safe to remove if the result is unused. This is an existing feature that you can trigger by manually adding a `/* @__PURE__ */` comment before a constructor call. The difference is that this release contains special behavior to automatically mark `Set` and `Map` as pure for you as long as it's safe to do so. As with all constructor calls that are marked `/* @__PURE__ */`, any internal expressions which could cause side effects are still preserved even though the constructor call itself is removed:
```js
// Original code
new Map([
['a', b()],
[c(), new Set(['d', e()])],
]);
// Old output (with --minify)
new Map([["a",b()],[c(),new Set(["d",e()])]]);
// New output (with --minify)
b(),c(),e();
```
### [`v0.13.15`](https://togithub.com/evanw/esbuild/blob/master/CHANGELOG.md#01315)
[Compare Source](https://togithub.com/evanw/esbuild/compare/v0.13.14...v0.13.15)
- Fix `super` in lowered `async` arrow functions ([#1777](https://togithub.com/evanw/esbuild/issues/1777))
This release fixes an edge case that was missed when lowering `async` arrow functions containing `super` property accesses for compile targets that don't support `async` such as with `--target=es6`. The problem was that lowering transforms `async` arrow functions into generator function expressions that are then passed to an esbuild helper function called `__async` that implements the `async` state machine behavior. Since function expressions do not capture `this` and `super` like arrow functions do, this led to a mismatch in behavior which meant that the transform was incorrect. The fix is to introduce a helper function to forward `super` access into the generator function expression body. Here's an example:
```js
// Original code
class Foo extends Bar {
foo() { return async () => super.bar() }
}
// Old output (with --target=es6)
class Foo extends Bar {
foo() {
return () => __async(this, null, function* () {
return super.bar();
});
}
}
// New output (with --target=es6)
class Foo extends Bar {
foo() {
return () => {
var __superGet = (key) => super[key];
return __async(this, null, function* () {
return __superGet("bar").call(this);
});
};
}
}
```
- Avoid merging certain CSS rules with different units ([#1732](https://togithub.com/evanw/esbuild/issues/1732))
This release no longer collapses `border-radius`, `margin`, `padding`, and `inset` rules when they have units with different levels of browser support. Collapsing multiple of these rules into a single rule is not equivalent if the browser supports one unit but not the other unit, since one rule would still have applied before the collapse but no longer applies after the collapse due to the whole rule being ignored. For example, Chrome 10 supports the `rem` unit but not the `vw` unit, so the CSS code below should render with rounded corners in Chrome 10. However, esbuild previously merged everything into a single rule which would cause Chrome 10 to ignore the rule and not round the corners. This issue is now fixed:
```css
/* Original CSS */
div {
border-radius: 1rem;
border-top-left-radius: 1vw;
margin: 0;
margin-top: 1Q;
left: 10Q;
top: 20Q;
right: 10Q;
bottom: 20Q;
}
/* Old output (with --minify) */
div{border-radius:1vw 1rem 1rem;margin:1Q 0 0;inset:20Q 10Q}
/* New output (with --minify) */
div{border-radius:1rem;border-top-left-radius:1vw;margin:0;margin-top:1Q;inset:20Q 10Q}
```
Notice how esbuild can still collapse rules together when they all share the same unit, even if the unit is one that doesn't have universal browser support such as the unit `Q`. One subtlety is that esbuild now distinguishes between "safe" and "unsafe" units where safe units are old enough that they are guaranteed to work in any browser a user might reasonably use, such as `px`. Safe units are allowed to be collapsed together even if there are multiple different units while multiple different unsafe units are not allowed to be collapsed together. Another detail is that esbuild no longer minifies zero lengths by removing the unit if the unit is unsafe (e.g. `0rem` into `0`) since that could cause a rendering difference if a previously-ignored rule is now no longer ignored due to the unit change. If you are curious, you can learn more about browser support levels for different CSS units in [Mozilla's documentation about CSS length units](https://developer.mozilla.org/en-US/docs/Web/CSS/length).
- Avoid warning about ignored side-effect free imports for empty files ([#1785](https://togithub.com/evanw/esbuild/issues/1785))
When bundling, esbuild warns about bare imports such as `import "lodash-es"` when the package has been marked as `"sideEffects": false` in its `package.json` file. This is because the only reason to use a bare import is because you are relying on the side effects of the import, but imports for packages marked as side-effect free are supposed to be removed. If the package indicates that it has no side effects, then this bare import is likely a bug.
However, some people have packages just for TypeScript type definitions. These package can actually have a side effect as they can augment the type of the global object in TypeScript, even if they are marked with `"sideEffects": false`. To avoid warning in this case, esbuild will now only issue this warning if the imported file is non-empty. If the file is empty, then it's irrelevant whether you import it or not so any import of that file does not indicate a bug. This fixes this case because `.d.ts` files typically end up being empty after esbuild parses them since they typically only contain type declarations.
- Attempt to fix packages broken due to the `node:` prefix ([#1760](https://togithub.com/evanw/esbuild/issues/1760))
Some people have started using the node-specific `node:` path prefix in their packages. This prefix forces the following path to be interpreted as a node built-in module instead of a package on the file system. So `require("node:path")` will always import [node's `path` module](https://nodejs.org/api/path.html) and never import [npm's `path` package](https://www.npmjs.com/package/path).
Adding the `node:` prefix breaks that code with older node versions that don't understand the `node:` prefix. This is a problem with the package, not with esbuild. The package should be adding a fallback if the `node:` prefix isn't available. However, people still want to be able to use these packages with older node versions even though the code is broken. Now esbuild will automatically strip this prefix if it detects that the code will break in the configured target environment (as specified by `--target=`). Note that this only happens during bundling, since import paths are only examined during bundling.
### [`v0.13.14`](https://togithub.com/evanw/esbuild/blob/master/CHANGELOG.md#01314)
[Compare Source](https://togithub.com/evanw/esbuild/compare/v0.13.13...v0.13.14)
- Fix dynamic `import()` on node 12.20+ ([#1772](https://togithub.com/evanw/esbuild/issues/1772))
When you use flags such as `--target=node12.20`, esbuild uses that version number to see what features the target environment supports. This consults an internal table that stores which target environments are supported for each feature. For example, `import(x)` is changed into `Promise.resolve().then(() => require(x))` if dynamic `import` expressions are unsupported.
Previously esbuild's internal table only stored one version number, since features are rarely ever removed in newer versions of software. Either the target environment is before that version and the feature is unsupported, or the target environment is after that version and the feature is supported. This approach has work for all relevant features in all cases except for one: dynamic `import` support in node. This feature is supported in node 12.20.0 up to but not including node 13.0.0, and then is also supported in node 13.2.0 up. The feature table implementation has been changed to store an array of potentially discontiguous version ranges instead of one version number.
Up until now, esbuild used 13.2.0 as the lowest supported version number to avoid generating dynamic `import` expressions when targeting node versions that don't support it. But with this release, esbuild will now use the more accurate discontiguous version range in this case. This means dynamic `import` expressions can now be generated when targeting versions of node 12.20.0 up to but not including node 13.0.0.
- Avoid merging certain qualified rules in CSS ([#1776](https://togithub.com/evanw/esbuild/issues/1776))
A change was introduced in the previous release to merge adjacent CSS rules that have the same content:
```css
/* Original code */
a { color: red }
b { color: red }
/* Minified output */
a,b{color:red}
```
However, that introduced a regression in cases where the browser considers one selector to be valid and the other selector to be invalid, such as in the following example:
```css
/* This rule is valid, and is applied */
a { color: red }
/* This rule is invalid, and is ignored */
b:-x-invalid { color: red }
```
Merging these two rules into one causes the browser to consider the entire merged rule to be invalid, which disables both rules. This is a change in behavior from the original code.
With this release, esbuild will now only merge adjacent duplicate rules together if they are known to work in all browsers (specifically, if they are known to work in IE 7 and up). Adjacent duplicate rules will no longer be merged in all other cases including modern pseudo-class selectors such as `:focus`, HTML5 elements such as `video`, and combinators such as `a + b`.
- Minify syntax in the CSS `font`, `font-family`, and `font-weight` properties ([#1756](https://togithub.com/evanw/esbuild/pull/1756))
This release includes size reductions for CSS font syntax when minification is enabled:
```css
/* Original code */
div {
font: bold 1rem / 1.2 "Segoe UI", sans-serif, "Segoe UI Emoji";
}
/* Output with "--minify" */
div{font:700 1rem/1.2 Segoe UI,sans-serif,"Segoe UI Emoji"}
```
Notice how `bold` has been changed to `700` and the quotes were removed around `"Segoe UI"` since it was safe to do so.
This feature was contributed by [@sapphi-red](https://togithub.com/sapphi-red).
### [`v0.13.13`](https://togithub.com/evanw/esbuild/blob/master/CHANGELOG.md#01313)
[Compare Source](https://togithub.com/evanw/esbuild/compare/v0.13.12...v0.13.13)
- Add more information about skipping `"main"` in `package.json` ([#1754](https://togithub.com/evanw/esbuild/issues/1754))
Configuring `mainFields: []` breaks most npm packages since it tells esbuild to ignore the `"main"` field in `package.json`, which most npm packages use to specify their entry point. This is not a bug with esbuild because esbuild is just doing what it was told to do. However, people may do this without understanding how npm packages work, and then be confused about why it doesn't work. This release now includes additional information in the error message:
> foo.js:1:27: error: Could not resolve "events" (use "--platform=node" when building for node)
1 │ var EventEmitter = require('events')
╵ ~~~~~~~~
node_modules/events/package.json:20:2: note: The "main" field was ignored because the list of main fields to use is currently set to []
20 │ "main": "./events.js",
╵ ~~~~~~
- Fix a tree-shaking bug with `var exports` ([#1739](https://togithub.com/evanw/esbuild/issues/1739))
This release fixes a bug where a variable named `var exports = {}` was incorrectly removed by tree-shaking (i.e. dead code elimination). The `exports` variable is a special variable in CommonJS modules that is automatically provided by the CommonJS runtime. CommonJS modules are transformed into something like this before being run:
```js
function(exports, module, require) {
var exports = {}
}
```
So using `var exports = {}` should have the same effect as `exports = {}` because the variable `exports` should already be defined. However, esbuild was incorrectly overwriting the definition of the `exports` variable with the one provided by CommonJS. This release merges the definitions together so both are included, which fixes the bug.
- Merge adjacent CSS selector rules with duplicate content ([#1755](https://togithub.com/evanw/esbuild/issues/1755))
With this release, esbuild will now merge adjacent selectors when minifying if they have the same content:
```css
/* Original code */
a { color: red }
b { color: red }
/* Old output (with --minify) */
a{color:red}b{color:red}
/* New output (with --minify) */
a,b{color:red}
```
- Shorten `top`, `right`, `bottom`, `left` CSS property into `inset` when it is supported ([#1758](https://togithub.com/evanw/esbuild/pull/1758))
This release enables collapsing of `inset` related properties:
```css
/* Original code */
div {
top: 0;
right: 0;
bottom: 0;
left: 0;
}
/* Output with "--minify-syntax" */
div {
inset: 0;
}
```
This minification rule is only enabled when `inset` property is supported by the target environment. Make sure to set esbuild's `target` setting correctly when minifying if the code will be running in an older environment (e.g. earlier than Chrome 87).
This feature was contributed by [@sapphi-red](https://togithub.com/sapphi-red).
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.13.12->0.14.1Release Notes
evanw/esbuild
### [`v0.14.1`](https://togithub.com/evanw/esbuild/blob/master/CHANGELOG.md#0141) [Compare Source](https://togithub.com/evanw/esbuild/compare/v0.14.0...v0.14.1) - Fix `imports` in `package.json` ([#1807](https://togithub.com/evanw/esbuild/issues/1807)) This release contains a fix for the rarely-used [`imports` feature in `package.json` files](https://nodejs.org/api/packages.html#subpath-imports) that lets a package specify a custom remapping for import paths inside that package that start with `#`. Support for `imports` was added in version 0.13.9. However, the field was being incorrectly interpreted as relative to the importing file instead of to the `package.json` file, which caused an import failure when the importing file is in a subdirectory instead of being at the top level of the package. Import paths should now be interpreted as relative to the correct directory which should fix these path resolution failures. - Isolate implicit sibling scope lookup for `enum` and `namespace` The previous release implemented sibling namespaces in TypeScript, which introduces a new kind of scope lookup that doesn't exist in JavaScript. Exported members inside an `enum` or `namespace` block can be implicitly referenced in a sibling `enum` or `namespace` block just by using the name without using a property reference. However, this behavior appears to only work for `enum`-to-`enum` and `namespace`-to-`namespace` interactions. Even though sibling enums and namespaces with the same name can be merged together into the same underlying object, this implicit reference behavior doesn't work for `enum`-to-`namespace` interactions and attempting to do this with a `namespace`-to-`enum` interaction [causes the TypeScript compiler itself to crash](https://togithub.com/microsoft/TypeScript/issues/46891). Here is an example of how the TypeScript compiler behaves in each case: ```ts // "b" is accessible enum a { b = 1 } enum a { c = b } // "e" is accessible namespace d { export let e = 1 } namespace d { export let f = e } // "h" is inaccessible enum g { h = 1 } namespace g { export let i = h } // This causes the TypeScript compiler to crash namespace j { export let k = 1 } enum j { l = k } ``` This release changes the implicit sibling scope lookup behavior to only work for `enum`-to-`enum` and `namespace`-to-`namespace` interactions. These implicit references no longer work with `enum`-to-`namespace` and `namespace`-to-`enum` interactions, which should more accurately match the behavior of the TypeScript compiler. - Add semicolon insertion before TypeScript-specific definite assignment assertion modifier ([#1810](https://togithub.com/evanw/esbuild/issues/1810)) TypeScript lets you add a `!` after a variable declaration to bypass TypeScript's definite assignment analysis: ```ts let x!: number[]; initialize(); x.push(4); function initialize() { x = [0, 1, 2, 3]; } ``` This `!` is called a [definite assignment assertion](https://devblogs.microsoft.com/typescript/announcing-typescript-2-7/#definite-assignment-assertions) and tells TypeScript to assume that the variable has been initialized somehow. However, JavaScript's automatic semicolon insertion rules should be able to insert a semicolon before it: ```ts let a !function(){}() ``` Previously the above code was incorrectly considered a syntax error in TypeScript. With this release, this code is now parsed correctly. - Log output to stderr has been overhauled This release changes the way log messages are formatted to stderr. The changes make the kind of message (e.g. error vs. warning vs. note) more obvious, and they also give more room for paragraph-style notes that can provide more detail about the message. Here's an example: Before: > example.tsx:14:25: warning: Comparison with -0 using the "===" operator will also match 0 14 │ case 1: return x === -0 ╵ ~~ > example.tsx:21:23: error: Could not resolve "path" (use "--platform=node" when building for node) 21 │ const path = require('path') ╵ ~~~~~~ After: ▲ [WARNING] Comparison with -0 using the "===" operator will also match 0 example.tsx:14:25: 14 │ case 1: return x === -0 ╵ ~~ Floating-point equality is defined such that 0 and -0 are equal, so "x === -0" returns true for both 0 and -0. You need to use "Object.is(x, -0)" instead to test for -0. ✘ [ERROR] Could not resolve "path" example.tsx:21:23: 21 │ const path = require('path') ╵ ~~~~~~ The package "path" wasn't found on the file system but is built into node. Are you trying to bundle for node? You can use "--platform=node" to do that, which will remove this error. Note that esbuild's formatted log output is for humans, not for machines. If you need to output a stable machine-readable format, you should be using the API for that. Build and transform results have arrays called `errors` and `warnings` with objects that represent the log messages. - Show inlined enum value names in comments When esbuild inlines an enum, it will now put a comment next to it with the original enum name: ```ts // Original code const enum Foo { FOO } console.log(Foo.FOO) // Old output console.log(0); // New output console.log(0 /* FOO */); ``` This matches the behavior of the TypeScript compiler, and should help with debugging. These comments are not generated if minification is enabled. ### [`v0.14.0`](https://togithub.com/evanw/esbuild/blob/master/CHANGELOG.md#0140) [Compare Source](https://togithub.com/evanw/esbuild/compare/v0.13.15...v0.14.0) **This release contains backwards-incompatible changes.** Since esbuild is before version 1.0.0, these changes have been released as a new minor version to reflect this (as [recommended by npm](https://docs.npmjs.com/cli/v6/using-npm/semver/)). You should either be pinning the exact version of `esbuild` in your `package.json` file or be using a version range syntax that only accepts patch upgrades such as `~0.13.0`. See the documentation about [semver](https://docs.npmjs.com/cli/v6/using-npm/semver/) for more information. - Add support for TypeScript's `preserveValueImports` setting ([#1525](https://togithub.com/evanw/esbuild/issues/1525)) TypeScript 4.5, which was just released, added [a new setting called `preserveValueImports`](https://devblogs.microsoft.com/typescript/announcing-typescript-4-5/#preserve-value-imports). This release of esbuild implements support for this new setting. However, this release also changes esbuild's behavior regarding the `importsNotUsedAsValues` setting, so this release is being considered a breaking change. Now esbuild's behavior should more accurately match the behavior of the TypeScript compiler. This is described in more detail below. The difference in behavior is around unused imports. By default, unused import names are considered to be types and are completely removed if they are unused. If all import names are removed for a given import statement, then the whole import statement is removed too. The two `tsconfig.json` settings [`importsNotUsedAsValues`](https://www.typescriptlang.org/tsconfig#importsNotUsedAsValues) and [`preserveValueImports`](https://www.typescriptlang.org/tsconfig#preserveValueImports) let you customize this. Here's what the TypeScript compiler's output looks like with these different settings enabled: ```ts // Original code import { unused } from "foo"; // Default output /* (the import is completely removed) */ // Output with "importsNotUsedAsValues": "preserve" import "foo"; // Output with "preserveValueImports": true import { unused } from "foo"; ``` Previously, since the `preserveValueImports` setting didn't exist yet, esbuild had treated the `importsNotUsedAsValues` setting as if it were what is now the `preserveValueImports` setting instead. This was a deliberate deviation from how the TypeScript compiler behaves, but was necessary to allow esbuild to be used as a TypeScript-to-JavaScript compiler inside of certain composite languages such as Svelte and Vue. These languages append additional code after converting the TypeScript to JavaScript so unused imports may actually turn out to be used later on: ```svelte ``` Previously the implementers of these languages had to use the `importsNotUsedAsValues` setting as a hack for esbuild to preserve the import statements. With this release, esbuild now follows the behavior of the TypeScript compiler so implementers will need to use the new `preserveValueImports` setting to do this instead. This is the breaking change. - TypeScript code follows JavaScript class field semantics with `--target=esnext` ([#1480](https://togithub.com/evanw/esbuild/issues/1480)) TypeScript 4.3 included a subtle breaking change that wasn't mentioned in the [TypeScript 4.3 blog post](https://devblogs.microsoft.com/typescript/announcing-typescript-4-3/): class fields will now be compiled with different semantics if `"target": "ESNext"` is present in `tsconfig.json`. Specifically in this case `useDefineForClassFields` will default to `true` when not specified instead of `false`. This means class field behavior in TypeScript code will now match JavaScript instead of doing something else: ```js class Base { set foo(value) { console.log('set', value) } } class Derived extends Base { foo = 123 } new Derived() ``` In TypeScript 4.2 and below, the TypeScript compiler would generate code that prints `set 123` when `tsconfig.json` contains `"target": "ESNext"` but in TypeScript 4.3 and above, the TypeScript compiler will now generate code that doesn't print anything. This is the difference between "assign" semantics and "define" semantics. Previously you had to create a `tsconfig.json` file and specify `"target": "ESNext"` to get this behavior in esbuild. With this release, you can now also just pass `--target=esnext` to esbuild to force-enable this behavior. Note that esbuild doesn't do this by default even though the default value of `--target=` otherwise behaves like `esnext`. Since TypeScript's compiler doesn't do this behavior by default, it seems like a good idea for esbuild to not do this behavior by default either. In addition to the breaking changes above, the following changes are also included in this release: - Allow certain keywords as tuple type labels in TypeScript ([#1797](https://togithub.com/evanw/esbuild/issues/1797)) Apparently TypeScript lets you use certain keywords as tuple labels but not others. For example, `type x = [function: number]` is allowed while `type x = [class: number]` isn't. This release replicates this behavior in esbuild's TypeScript parser: - Allowed keywords: `false`, `function`, `import`, `new`, `null`, `this`, `true`, `typeof`, `void` - Forbidden keywords: `break`, `case`, `catch`, `class`, `const`, `continue`, `debugger`, `default`, `delete`, `do`, `else`, `enum`, `export`, `extends`, `finally`, `for`, `if`, `in`, `instanceof`, `return`, `super`, `switch`, `throw`, `try`, `var`, `while`, `with` - Support sibling namespaces in TypeScript ([#1410](https://togithub.com/evanw/esbuild/issues/1410)) TypeScript has a feature where sibling namespaces with the same name can implicitly reference each other's exports without an explicit property access. This goes against how scope lookup works in JavaScript, so it previously didn't work with esbuild. This release adds support for this feature: ```ts // Original TypeScript code namespace x { export let y = 123 } namespace x { export let z = y } // Old JavaScript output var x; (function(x2) { x2.y = 123; })(x || (x = {})); (function(x2) { x2.z = y; })(x || (x = {})); // New JavaScript output var x; (function(x2) { x2.y = 123; })(x || (x = {})); (function(x2) { x2.z = x2.y; })(x || (x = {})); ``` Notice how the identifier `y` is now compiled to the property access `x2.y` which references the export named `y` on the namespace, instead of being left as the identifier `y` which references the global named `y`. This matches how the TypeScript compiler treats namespace objects. This new behavior also works for enums: ```ts // Original TypeScript code enum x { y = 123 } enum x { z = y + 1 } // Old JavaScript output var x; (function(x2) { x2[x2["y"] = 123] = "y"; })(x || (x = {})); (function(x2) { x2[x2["z"] = y + 1] = "z"; })(x || (x = {})); // New JavaScript output var x; (function(x2) { x2[x2["y"] = 123] = "y"; })(x || (x = {})); (function(x2) { x2[x2["z"] = 124] = "z"; })(x || (x = {})); ``` Note that this behavior does **not** work across files. Each file is still compiled independently so the namespaces in each file are still resolved independently per-file. Implicit namespace cross-references still do not work across files. Getting this to work is counter to esbuild's parallel architecture and does not fit in with esbuild's design. It also doesn't make sense with esbuild's bundling model where input files are either in ESM or CommonJS format and therefore each have their own scope. - Change output for top-level TypeScript enums The output format for top-level TypeScript enums has been changed to reduce code size and improve tree shaking, which means that esbuild's enum output is now somewhat different than TypeScript's enum output. The behavior of both output formats should still be equivalent though. Here's an example that shows the difference: ```ts // Original code enum x { y = 1, z = 2 } // Old output var x; (function(x2) { x2[x2["y"] = 1] = "y"; x2[x2["z"] = 2] = "z"; })(x || (x = {})); // New output var x = /* @__PURE__ */ ((x2) => { x2[x2["y"] = 1] = "y"; x2[x2["z"] = 2] = "z"; return x2; })(x || {}); ``` The function expression has been changed to an arrow expression to reduce code size and the enum initializer has been moved into the variable declaration to make it possible to be marked as `/* @__PURE__ */` to improve tree shaking. The `/* @__PURE__ */` annotation is now automatically added when all of the enum values are side-effect free, which means the entire enum definition can be removed as dead code if it's never referenced. Direct enum value references within the same file that have been inlined do not count as references to the enum definition so this should eliminate enums from the output in many cases: ```ts // Original code enum Foo { FOO = 1 } enum Bar { BAR = 2 } console.log(Foo, Bar.BAR) // Old output (with --bundle --minify) var n;(function(e){e[e.FOO=1]="FOO"})(n||(n={}));var l;(function(e){e[e.BAR=2]="BAR"})(l||(l={}));console.log(n,2); // New output (with --bundle --minify) var n=(e=>(e[e.FOO=1]="FOO",e))(n||{});console.log(n,2); ``` Notice how the new output is much shorter because the entire definition for `Bar` has been completely removed as dead code by esbuild's tree shaking. The output may seem strange since it would be simpler to just have a plain object literal as an initializer. However, TypeScript's enum feature behaves similarly to TypeScript's namespace feature which means enums can merge with existing enums and/or existing namespaces (and in some cases also existing objects) if the existing definition has the same name. This new output format keeps its similarity to the original output format so that it still handles all of the various edge cases that TypeScript's enum feature supports. Initializing the enum using a plain object literal would not merge with existing definitions and would break TypeScript's enum semantics. - Fix legal comment parsing in CSS ([#1796](https://togithub.com/evanw/esbuild/issues/1796)) Legal comments in CSS either start with `/*!` or contain `@preserve` or `@license` and are preserved by esbuild in the generated CSS output. This release fixes a bug where non-top-level legal comments inside a CSS file caused esbuild to skip any following legal comments even if those following comments are top-level: ```css /* Original code */ .example { --some-var: var(--tw-empty, /*!*/ /*!*/); } /*! Some legal comment */ body { background-color: red; } /* Old output (with --minify) */ .example{--some-var: var(--tw-empty, )}body{background-color:red} /* New output (with --minify) */ .example{--some-var: var(--tw-empty, )}/*! Some legal comment */body{background-color:red} ``` - Fix panic when printing invalid CSS ([#1803](https://togithub.com/evanw/esbuild/issues/1803)) This release fixes a panic caused by a conditional CSS `@import` rule with a URL token. Code like this caused esbuild to enter an unexpected state because the case where tokens in the import condition with associated import records wasn't handled. This case is now handled correctly: ```css @import "example.css" url(foo); ``` - Mark `Set` and `Map` with array arguments as pure ([#1791](https://togithub.com/evanw/esbuild/issues/1791)) This release introduces special behavior for references to the global `Set` and `Map` constructors that marks them as `/* @__PURE__ */` if they are known to not have any side effects. These constructors evaluate the iterator of whatever is passed to them and the iterator could have side effects, so this is only safe if whatever is passed to them is an array, since the array iterator has no side effects. Marking a constructor call as `/* @__PURE__ */` means it's safe to remove if the result is unused. This is an existing feature that you can trigger by manually adding a `/* @__PURE__ */` comment before a constructor call. The difference is that this release contains special behavior to automatically mark `Set` and `Map` as pure for you as long as it's safe to do so. As with all constructor calls that are marked `/* @__PURE__ */`, any internal expressions which could cause side effects are still preserved even though the constructor call itself is removed: ```js // Original code new Map([ ['a', b()], [c(), new Set(['d', e()])], ]); // Old output (with --minify) new Map([["a",b()],[c(),new Set(["d",e()])]]); // New output (with --minify) b(),c(),e(); ``` ### [`v0.13.15`](https://togithub.com/evanw/esbuild/blob/master/CHANGELOG.md#01315) [Compare Source](https://togithub.com/evanw/esbuild/compare/v0.13.14...v0.13.15) - Fix `super` in lowered `async` arrow functions ([#1777](https://togithub.com/evanw/esbuild/issues/1777)) This release fixes an edge case that was missed when lowering `async` arrow functions containing `super` property accesses for compile targets that don't support `async` such as with `--target=es6`. The problem was that lowering transforms `async` arrow functions into generator function expressions that are then passed to an esbuild helper function called `__async` that implements the `async` state machine behavior. Since function expressions do not capture `this` and `super` like arrow functions do, this led to a mismatch in behavior which meant that the transform was incorrect. The fix is to introduce a helper function to forward `super` access into the generator function expression body. Here's an example: ```js // Original code class Foo extends Bar { foo() { return async () => super.bar() } } // Old output (with --target=es6) class Foo extends Bar { foo() { return () => __async(this, null, function* () { return super.bar(); }); } } // New output (with --target=es6) class Foo extends Bar { foo() { return () => { var __superGet = (key) => super[key]; return __async(this, null, function* () { return __superGet("bar").call(this); }); }; } } ``` - Avoid merging certain CSS rules with different units ([#1732](https://togithub.com/evanw/esbuild/issues/1732)) This release no longer collapses `border-radius`, `margin`, `padding`, and `inset` rules when they have units with different levels of browser support. Collapsing multiple of these rules into a single rule is not equivalent if the browser supports one unit but not the other unit, since one rule would still have applied before the collapse but no longer applies after the collapse due to the whole rule being ignored. For example, Chrome 10 supports the `rem` unit but not the `vw` unit, so the CSS code below should render with rounded corners in Chrome 10. However, esbuild previously merged everything into a single rule which would cause Chrome 10 to ignore the rule and not round the corners. This issue is now fixed: ```css /* Original CSS */ div { border-radius: 1rem; border-top-left-radius: 1vw; margin: 0; margin-top: 1Q; left: 10Q; top: 20Q; right: 10Q; bottom: 20Q; } /* Old output (with --minify) */ div{border-radius:1vw 1rem 1rem;margin:1Q 0 0;inset:20Q 10Q} /* New output (with --minify) */ div{border-radius:1rem;border-top-left-radius:1vw;margin:0;margin-top:1Q;inset:20Q 10Q} ``` Notice how esbuild can still collapse rules together when they all share the same unit, even if the unit is one that doesn't have universal browser support such as the unit `Q`. One subtlety is that esbuild now distinguishes between "safe" and "unsafe" units where safe units are old enough that they are guaranteed to work in any browser a user might reasonably use, such as `px`. Safe units are allowed to be collapsed together even if there are multiple different units while multiple different unsafe units are not allowed to be collapsed together. Another detail is that esbuild no longer minifies zero lengths by removing the unit if the unit is unsafe (e.g. `0rem` into `0`) since that could cause a rendering difference if a previously-ignored rule is now no longer ignored due to the unit change. If you are curious, you can learn more about browser support levels for different CSS units in [Mozilla's documentation about CSS length units](https://developer.mozilla.org/en-US/docs/Web/CSS/length). - Avoid warning about ignored side-effect free imports for empty files ([#1785](https://togithub.com/evanw/esbuild/issues/1785)) When bundling, esbuild warns about bare imports such as `import "lodash-es"` when the package has been marked as `"sideEffects": false` in its `package.json` file. This is because the only reason to use a bare import is because you are relying on the side effects of the import, but imports for packages marked as side-effect free are supposed to be removed. If the package indicates that it has no side effects, then this bare import is likely a bug. However, some people have packages just for TypeScript type definitions. These package can actually have a side effect as they can augment the type of the global object in TypeScript, even if they are marked with `"sideEffects": false`. To avoid warning in this case, esbuild will now only issue this warning if the imported file is non-empty. If the file is empty, then it's irrelevant whether you import it or not so any import of that file does not indicate a bug. This fixes this case because `.d.ts` files typically end up being empty after esbuild parses them since they typically only contain type declarations. - Attempt to fix packages broken due to the `node:` prefix ([#1760](https://togithub.com/evanw/esbuild/issues/1760)) Some people have started using the node-specific `node:` path prefix in their packages. This prefix forces the following path to be interpreted as a node built-in module instead of a package on the file system. So `require("node:path")` will always import [node's `path` module](https://nodejs.org/api/path.html) and never import [npm's `path` package](https://www.npmjs.com/package/path). Adding the `node:` prefix breaks that code with older node versions that don't understand the `node:` prefix. This is a problem with the package, not with esbuild. The package should be adding a fallback if the `node:` prefix isn't available. However, people still want to be able to use these packages with older node versions even though the code is broken. Now esbuild will automatically strip this prefix if it detects that the code will break in the configured target environment (as specified by `--target=`). Note that this only happens during bundling, since import paths are only examined during bundling. ### [`v0.13.14`](https://togithub.com/evanw/esbuild/blob/master/CHANGELOG.md#01314) [Compare Source](https://togithub.com/evanw/esbuild/compare/v0.13.13...v0.13.14) - Fix dynamic `import()` on node 12.20+ ([#1772](https://togithub.com/evanw/esbuild/issues/1772)) When you use flags such as `--target=node12.20`, esbuild uses that version number to see what features the target environment supports. This consults an internal table that stores which target environments are supported for each feature. For example, `import(x)` is changed into `Promise.resolve().then(() => require(x))` if dynamic `import` expressions are unsupported. Previously esbuild's internal table only stored one version number, since features are rarely ever removed in newer versions of software. Either the target environment is before that version and the feature is unsupported, or the target environment is after that version and the feature is supported. This approach has work for all relevant features in all cases except for one: dynamic `import` support in node. This feature is supported in node 12.20.0 up to but not including node 13.0.0, and then is also supported in node 13.2.0 up. The feature table implementation has been changed to store an array of potentially discontiguous version ranges instead of one version number. Up until now, esbuild used 13.2.0 as the lowest supported version number to avoid generating dynamic `import` expressions when targeting node versions that don't support it. But with this release, esbuild will now use the more accurate discontiguous version range in this case. This means dynamic `import` expressions can now be generated when targeting versions of node 12.20.0 up to but not including node 13.0.0. - Avoid merging certain qualified rules in CSS ([#1776](https://togithub.com/evanw/esbuild/issues/1776)) A change was introduced in the previous release to merge adjacent CSS rules that have the same content: ```css /* Original code */ a { color: red } b { color: red } /* Minified output */ a,b{color:red} ``` However, that introduced a regression in cases where the browser considers one selector to be valid and the other selector to be invalid, such as in the following example: ```css /* This rule is valid, and is applied */ a { color: red } /* This rule is invalid, and is ignored */ b:-x-invalid { color: red } ``` Merging these two rules into one causes the browser to consider the entire merged rule to be invalid, which disables both rules. This is a change in behavior from the original code. With this release, esbuild will now only merge adjacent duplicate rules together if they are known to work in all browsers (specifically, if they are known to work in IE 7 and up). Adjacent duplicate rules will no longer be merged in all other cases including modern pseudo-class selectors such as `:focus`, HTML5 elements such as `video`, and combinators such as `a + b`. - Minify syntax in the CSS `font`, `font-family`, and `font-weight` properties ([#1756](https://togithub.com/evanw/esbuild/pull/1756)) This release includes size reductions for CSS font syntax when minification is enabled: ```css /* Original code */ div { font: bold 1rem / 1.2 "Segoe UI", sans-serif, "Segoe UI Emoji"; } /* Output with "--minify" */ div{font:700 1rem/1.2 Segoe UI,sans-serif,"Segoe UI Emoji"} ``` Notice how `bold` has been changed to `700` and the quotes were removed around `"Segoe UI"` since it was safe to do so. This feature was contributed by [@sapphi-red](https://togithub.com/sapphi-red). ### [`v0.13.13`](https://togithub.com/evanw/esbuild/blob/master/CHANGELOG.md#01313) [Compare Source](https://togithub.com/evanw/esbuild/compare/v0.13.12...v0.13.13) - Add more information about skipping `"main"` in `package.json` ([#1754](https://togithub.com/evanw/esbuild/issues/1754)) Configuring `mainFields: []` breaks most npm packages since it tells esbuild to ignore the `"main"` field in `package.json`, which most npm packages use to specify their entry point. This is not a bug with esbuild because esbuild is just doing what it was told to do. However, people may do this without understanding how npm packages work, and then be confused about why it doesn't work. This release now includes additional information in the error message: > foo.js:1:27: error: Could not resolve "events" (use "--platform=node" when building for node) 1 │ var EventEmitter = require('events') ╵ ~~~~~~~~ node_modules/events/package.json:20:2: note: The "main" field was ignored because the list of main fields to use is currently set to [] 20 │ "main": "./events.js", ╵ ~~~~~~ - Fix a tree-shaking bug with `var exports` ([#1739](https://togithub.com/evanw/esbuild/issues/1739)) This release fixes a bug where a variable named `var exports = {}` was incorrectly removed by tree-shaking (i.e. dead code elimination). The `exports` variable is a special variable in CommonJS modules that is automatically provided by the CommonJS runtime. CommonJS modules are transformed into something like this before being run: ```js function(exports, module, require) { var exports = {} } ``` So using `var exports = {}` should have the same effect as `exports = {}` because the variable `exports` should already be defined. However, esbuild was incorrectly overwriting the definition of the `exports` variable with the one provided by CommonJS. This release merges the definitions together so both are included, which fixes the bug. - Merge adjacent CSS selector rules with duplicate content ([#1755](https://togithub.com/evanw/esbuild/issues/1755)) With this release, esbuild will now merge adjacent selectors when minifying if they have the same content: ```css /* Original code */ a { color: red } b { color: red } /* Old output (with --minify) */ a{color:red}b{color:red} /* New output (with --minify) */ a,b{color:red} ``` - Shorten `top`, `right`, `bottom`, `left` CSS property into `inset` when it is supported ([#1758](https://togithub.com/evanw/esbuild/pull/1758)) This release enables collapsing of `inset` related properties: ```css /* Original code */ div { top: 0; right: 0; bottom: 0; left: 0; } /* Output with "--minify-syntax" */ div { inset: 0; } ``` This minification rule is only enabled when `inset` property is supported by the target environment. Make sure to set esbuild's `target` setting correctly when minifying if the code will be running in an older environment (e.g. earlier than Chrome 87). This feature was contributed by [@sapphi-red](https://togithub.com/sapphi-red).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.