evanw/esbuild
### [`v0.14.9`](https://togithub.com/evanw/esbuild/blob/HEAD/CHANGELOG.md#0149)
[Compare Source](https://togithub.com/evanw/esbuild/compare/v0.14.8...v0.14.9)
- Implement cross-module tree shaking of TypeScript enum values ([#128](https://togithub.com/evanw/esbuild/issues/128))
If your bundle uses TypeScript enums across multiple files, esbuild is able to inline the enum values as long as you export and import the enum using the ES module `export` and `import` keywords. However, this previously still left the definition of the enum in the bundle even when it wasn't used anymore. This was because esbuild's tree shaking (i.e. dead code elimination) is based on information recorded during parsing, and at that point we don't know which imported symbols are inlined enum values and which aren't.
With this release, esbuild will now remove enum definitions that become unused due to cross-module enum value inlining. Property accesses off of imported symbols are now tracked separately during parsing and then resolved during linking once all inlined enum values are known. This behavior change means esbuild's support for cross-module inlining of TypeScript enums is now finally complete. Here's an example:
```js
// entry.ts
import { Foo } from './enum'
console.log(Foo.Bar)
// enum.ts
export enum Foo { Bar }
```
Bundling the example code above now results in the enum definition being completely removed from the bundle:
```js
// Old output (with --bundle --minify --format=esm)
var r=(o=>(o[o.Bar=0]="Bar",o))(r||{});console.log(0);
// New output (with --bundle --minify --format=esm)
console.log(0);
```
- Fix a regression with `export {} from` and CommonJS ([#1890](https://togithub.com/evanw/esbuild/issues/1890))
This release fixes a regression that was introduced by the change in 0.14.7 that avoids calling the `__toESM` wrapper for import statements that are converted to `require` calls and that don't use the `default` or `__esModule` export names. The previous change was correct for the `import {} from` syntax but not for the `export {} from` syntax, which meant that in certain cases with re-exported values, the value of the `default` import could be different than expected. This release fixes the regression.
- Warn about using `module` or `exports` in ESM code ([#1887](https://togithub.com/evanw/esbuild/issues/1887))
CommonJS export variables cannot be referenced in ESM code. If you do this, they are treated as global variables instead. This release includes a warning for people that try to use both CommonJS and ES module export styles in the same file. Here's an example:
```ts
export enum Something {
a,
b,
}
module.exports = { a: 1, b: 2 }
```
Running esbuild on that code now generates a warning that looks like this:
▲ [WARNING] The CommonJS "module" variable is treated as a global variable in an ECMAScript module and may not work as expected
example.ts:5:0:
5 │ module.exports = { a: 1, b: 2 }
╵ ~~~~~~
This file is considered to be an ECMAScript module because of the "export" keyword here:
example.ts:1:0:
1 │ export enum Something {
╵ ~~~~~~
### [`v0.14.8`](https://togithub.com/evanw/esbuild/blob/HEAD/CHANGELOG.md#0148)
[Compare Source](https://togithub.com/evanw/esbuild/compare/v0.14.7...v0.14.8)
- Add a `resolve` API for plugins ([#641](https://togithub.com/evanw/esbuild/issues/641), [#1652](https://togithub.com/evanw/esbuild/issues/1652))
Plugins now have access to a new API called `resolve` that runs esbuild's path resolution logic and returns the result to the caller. This lets you write plugins that can reuse esbuild's complex built-in path resolution logic to change the inputs and/or adjust the outputs. Here's an example:
```js
let examplePlugin = {
name: 'example',
setup(build) {
build.onResolve({ filter: /^example$/ }, async () => {
const result = await build.resolve('./foo', { resolveDir: '/bar' })
if (result.errors.length > 0) return result
return { ...result, external: true }
})
},
}
```
This plugin intercepts imports to the path `example`, tells esbuild to resolve the import `./foo` in the directory `/bar`, and then forces whatever path esbuild returns to be considered external. Here are some additional details:
- If you don't pass the optional `resolveDir` parameter, esbuild will still run `onResolve` plugin callbacks but will not attempt any path resolution itself. All of esbuild's path resolution logic depends on the `resolveDir` parameter including looking for packages in `node_modules` directories (since it needs to know where those `node_modules` directories might be).
- If you want to resolve a file name in a specific directory, make sure the input path starts with `./`. Otherwise the input path will be treated as a package path instead of a relative path. This behavior is identical to esbuild's normal path resolution logic.
- If path resolution fails, the `errors` property on the returned object will be a non-empty array containing the error information. This function does not always throw an error when it fails. You need to check for errors after calling it.
- The behavior of this function depends on the build configuration. That's why it's a property of the `build` object instead of being a top-level API call. This also means you can't call it until all plugin `setup` functions have finished since these give plugins the opportunity to adjust the build configuration before it's frozen at the start of the build. So the new `resolve` function is going to be most useful inside your `onResolve` and/or `onLoad` callbacks.
- There is currently no attempt made to detect infinite path resolution loops. Calling `resolve` from within `onResolve` with the same parameters is almost certainly a bad idea.
- Avoid the CJS-to-ESM wrapper in some cases ([#1831](https://togithub.com/evanw/esbuild/issues/1831))
Import statements are converted into `require()` calls when the output format is set to CommonJS. To convert from CommonJS semantics to ES module semantics, esbuild wraps the return value in a call to esbuild's `__toESM()` helper function. However, the conversion is only needed if it's possible that the exports named `default` or `__esModule` could be accessed.
This release avoids calling this helper function in cases where esbuild knows it's impossible for the `default` or `__esModule` exports to be accessed, which results in smaller and faster code. To get this behavior, you have to use the `import {} from` import syntax:
```js
// Original code
import { readFile } from "fs";
readFile();
// Old output (with --format=cjs)
var __toESM = (module, isNodeMode) => {
...
};
var import_fs = __toESM(require("fs"));
(0, import_fs.readFile)();
// New output (with --format=cjs)
var import_fs = require("fs");
(0, import_fs.readFile)();
```
- Strip overwritten function declarations when minifying ([#610](https://togithub.com/evanw/esbuild/issues/610))
JavaScript allows functions to be re-declared, with each declaration overwriting the previous declaration. This type of code can sometimes be emitted by automatic code generators. With this release, esbuild now takes this behavior into account when minifying to drop all but the last declaration for a given function:
```js
// Original code
function foo() { console.log(1) }
function foo() { console.log(2) }
// Old output (with --minify)
function foo(){console.log(1)}function foo(){console.log(2)}
// New output (with --minify)
function foo(){console.log(2)}
```
- Add support for the Linux IBM Z 64-bit Big Endian platform ([#1864](https://togithub.com/evanw/esbuild/pull/1864))
With this release, the esbuild package now includes a Linux binary executable for the IBM System/390 64-bit architecture. This new platform was contributed by [@shahidhs-ibm](https://togithub.com/shahidhs-ibm).
- Allow whitespace around `:` in JSX elements ([#1877](https://togithub.com/evanw/esbuild/issues/1877))
This release allows you to write the JSX `` as `` instead. Doing this is not forbidden by [the JSX specification](https://facebook.github.io/jsx/). While this doesn't work in TypeScript, it does work with other JSX parsers in the ecosystem, so support for this has been added to esbuild.
### [`v0.14.7`](https://togithub.com/evanw/esbuild/blob/HEAD/CHANGELOG.md#0147)
[Compare Source](https://togithub.com/evanw/esbuild/compare/v0.14.6...v0.14.7)
- Cross-module inlining of TypeScript `enum` constants ([#128](https://togithub.com/evanw/esbuild/issues/128))
This release adds inlining of TypeScript `enum` constants across separate modules. It activates when bundling is enabled and when the enum is exported via the `export` keyword and imported via the `import` keyword:
```ts
// foo.ts
export enum Foo { Bar }
// bar.ts
import { Foo } from './foo.ts'
console.log(Foo.Bar)
```
The access to `Foo.Bar` will now be compiled into `0 /* Bar */` even though the enum is defined in a separate file. This inlining was added without adding another pass (which would have introduced a speed penalty) by splitting the code for the inlining between the existing parsing and printing passes. Enum inlining is active whether or not you use `enum` or `const enum` because it improves performance.
To demonstrate the performance improvement, I compared the performance of the TypeScript compiler built by bundling the TypeScript compiler source code with esbuild before and after this change. The speed of the compiler was measured by using it to type check a small TypeScript code base. Here are the results:
| | `tsc` | with esbuild 0.14.6 | with esbuild 0.14.7 |
|------|-------|---------------------|---------------------|
| Time | 2.96s | 3.45s | 2.95s |
As you can see, enum inlining gives around a 15% speedup, which puts the esbuild-bundled version at the same speed as the offical TypeScript compiler build (the `tsc` column)!
The specifics of the benchmark aren't important here since it's just a demonstration of how enum inlining can affect performance. But if you're wondering, I type checked the [Rollup](https://togithub.com/rollup/rollup) code base using a work-in-progress branch of the TypeScript compiler that's part of the ongoing effort to convert their use of namespaces into ES modules.
- Mark node built-in modules as having no side effects ([#705](https://togithub.com/evanw/esbuild/issues/705))
This release marks node built-in modules such as `fs` as being side-effect free. That means unused imports to these modules are now removed when bundling, which sometimes results in slightly smaller code. For example:
```js
// Original code
import fs from 'fs';
import path from 'path';
console.log(path.delimiter);
// Old output (with --bundle --minify --platform=node --format=esm)
import"fs";import o from"path";console.log(o.delimiter);
// New output (with --bundle --minify --platform=node --format=esm)
import o from"path";console.log(o.delimiter);
```
Note that these modules are only automatically considered side-effect when bundling for node, since they are only known to be side-effect free imports in that environment. However, you can customize this behavior with a plugin by returning `external: true` and `sideEffects: false` in an `onResolve` callback for whatever paths you want to be treated this way.
- Recover from a stray top-level `}` in CSS ([#1876](https://togithub.com/evanw/esbuild/pull/1876))
This release fixes a bug where a stray `}` at the top-level of a CSS file would incorrectly truncate the remainder of the file in the output (although not without a warning). With this release, the remainder of the file is now still parsed and printed:
```css
/* Original code */
.red {
color: red;
}
}
.blue {
color: blue;
}
.green {
color: green;
}
/* Old output (with --minify) */
.red{color:red}
/* New output (with --minify) */
.red{color:red}} .blue{color:#00f}.green{color:green}
```
This fix was contributed by [@sbfaulkner](https://togithub.com/sbfaulkner).
Configuration
📅 Schedule: At any time (no schedule defined).
🚦 Automerge: Disabled by config. Please merge this manually once you are satisfied.
♻ Rebasing: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox.
🔕 Ignore: Close this PR and you won't be reminded about this update again.
[ ] If you want to rebase/retry this PR, click this checkbox.
gitpod-io[bot]
commented
2 years ago 
This PR contains the following updates:
0.14.6->0.14.9Release Notes
evanw/esbuild
### [`v0.14.9`](https://togithub.com/evanw/esbuild/blob/HEAD/CHANGELOG.md#0149) [Compare Source](https://togithub.com/evanw/esbuild/compare/v0.14.8...v0.14.9) - Implement cross-module tree shaking of TypeScript enum values ([#128](https://togithub.com/evanw/esbuild/issues/128)) If your bundle uses TypeScript enums across multiple files, esbuild is able to inline the enum values as long as you export and import the enum using the ES module `export` and `import` keywords. However, this previously still left the definition of the enum in the bundle even when it wasn't used anymore. This was because esbuild's tree shaking (i.e. dead code elimination) is based on information recorded during parsing, and at that point we don't know which imported symbols are inlined enum values and which aren't. With this release, esbuild will now remove enum definitions that become unused due to cross-module enum value inlining. Property accesses off of imported symbols are now tracked separately during parsing and then resolved during linking once all inlined enum values are known. This behavior change means esbuild's support for cross-module inlining of TypeScript enums is now finally complete. Here's an example: ```js // entry.ts import { Foo } from './enum' console.log(Foo.Bar) // enum.ts export enum Foo { Bar } ``` Bundling the example code above now results in the enum definition being completely removed from the bundle: ```js // Old output (with --bundle --minify --format=esm) var r=(o=>(o[o.Bar=0]="Bar",o))(r||{});console.log(0); // New output (with --bundle --minify --format=esm) console.log(0); ``` - Fix a regression with `export {} from` and CommonJS ([#1890](https://togithub.com/evanw/esbuild/issues/1890)) This release fixes a regression that was introduced by the change in 0.14.7 that avoids calling the `__toESM` wrapper for import statements that are converted to `require` calls and that don't use the `default` or `__esModule` export names. The previous change was correct for the `import {} from` syntax but not for the `export {} from` syntax, which meant that in certain cases with re-exported values, the value of the `default` import could be different than expected. This release fixes the regression. - Warn about using `module` or `exports` in ESM code ([#1887](https://togithub.com/evanw/esbuild/issues/1887)) CommonJS export variables cannot be referenced in ESM code. If you do this, they are treated as global variables instead. This release includes a warning for people that try to use both CommonJS and ES module export styles in the same file. Here's an example: ```ts export enum Something { a, b, } module.exports = { a: 1, b: 2 } ``` Running esbuild on that code now generates a warning that looks like this: ▲ [WARNING] The CommonJS "module" variable is treated as a global variable in an ECMAScript module and may not work as expected example.ts:5:0: 5 │ module.exports = { a: 1, b: 2 } ╵ ~~~~~~ This file is considered to be an ECMAScript module because of the "export" keyword here: example.ts:1:0: 1 │ export enum Something { ╵ ~~~~~~ ### [`v0.14.8`](https://togithub.com/evanw/esbuild/blob/HEAD/CHANGELOG.md#0148) [Compare Source](https://togithub.com/evanw/esbuild/compare/v0.14.7...v0.14.8) - Add a `resolve` API for plugins ([#641](https://togithub.com/evanw/esbuild/issues/641), [#1652](https://togithub.com/evanw/esbuild/issues/1652)) Plugins now have access to a new API called `resolve` that runs esbuild's path resolution logic and returns the result to the caller. This lets you write plugins that can reuse esbuild's complex built-in path resolution logic to change the inputs and/or adjust the outputs. Here's an example: ```js let examplePlugin = { name: 'example', setup(build) { build.onResolve({ filter: /^example$/ }, async () => { const result = await build.resolve('./foo', { resolveDir: '/bar' }) if (result.errors.length > 0) return result return { ...result, external: true } }) }, } ``` This plugin intercepts imports to the path `example`, tells esbuild to resolve the import `./foo` in the directory `/bar`, and then forces whatever path esbuild returns to be considered external. Here are some additional details: - If you don't pass the optional `resolveDir` parameter, esbuild will still run `onResolve` plugin callbacks but will not attempt any path resolution itself. All of esbuild's path resolution logic depends on the `resolveDir` parameter including looking for packages in `node_modules` directories (since it needs to know where those `node_modules` directories might be). - If you want to resolve a file name in a specific directory, make sure the input path starts with `./`. Otherwise the input path will be treated as a package path instead of a relative path. This behavior is identical to esbuild's normal path resolution logic. - If path resolution fails, the `errors` property on the returned object will be a non-empty array containing the error information. This function does not always throw an error when it fails. You need to check for errors after calling it. - The behavior of this function depends on the build configuration. That's why it's a property of the `build` object instead of being a top-level API call. This also means you can't call it until all plugin `setup` functions have finished since these give plugins the opportunity to adjust the build configuration before it's frozen at the start of the build. So the new `resolve` function is going to be most useful inside your `onResolve` and/or `onLoad` callbacks. - There is currently no attempt made to detect infinite path resolution loops. Calling `resolve` from within `onResolve` with the same parameters is almost certainly a bad idea. - Avoid the CJS-to-ESM wrapper in some cases ([#1831](https://togithub.com/evanw/esbuild/issues/1831)) Import statements are converted into `require()` calls when the output format is set to CommonJS. To convert from CommonJS semantics to ES module semantics, esbuild wraps the return value in a call to esbuild's `__toESM()` helper function. However, the conversion is only needed if it's possible that the exports named `default` or `__esModule` could be accessed. This release avoids calling this helper function in cases where esbuild knows it's impossible for the `default` or `__esModule` exports to be accessed, which results in smaller and faster code. To get this behavior, you have to use the `import {} from` import syntax: ```js // Original code import { readFile } from "fs"; readFile(); // Old output (with --format=cjs) var __toESM = (module, isNodeMode) => { ... }; var import_fs = __toESM(require("fs")); (0, import_fs.readFile)(); // New output (with --format=cjs) var import_fs = require("fs"); (0, import_fs.readFile)(); ``` - Strip overwritten function declarations when minifying ([#610](https://togithub.com/evanw/esbuild/issues/610)) JavaScript allows functions to be re-declared, with each declaration overwriting the previous declaration. This type of code can sometimes be emitted by automatic code generators. With this release, esbuild now takes this behavior into account when minifying to drop all but the last declaration for a given function: ```js // Original code function foo() { console.log(1) } function foo() { console.log(2) } // Old output (with --minify) function foo(){console.log(1)}function foo(){console.log(2)} // New output (with --minify) function foo(){console.log(2)} ``` - Add support for the Linux IBM Z 64-bit Big Endian platform ([#1864](https://togithub.com/evanw/esbuild/pull/1864)) With this release, the esbuild package now includes a Linux binary executable for the IBM System/390 64-bit architecture. This new platform was contributed by [@shahidhs-ibm](https://togithub.com/shahidhs-ibm). - Allow whitespace around `:` in JSX elements ([#1877](https://togithub.com/evanw/esbuild/issues/1877)) This release allows you to write the JSX `Configuration
📅 Schedule: At any time (no schedule defined).
🚦 Automerge: Disabled by config. Please merge this manually once you are satisfied.
♻ Rebasing: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox.
🔕 Ignore: Close this PR and you won't be reminded about this update again.
This PR has been generated by WhiteSource Renovate. View repository job log here.