Bump esbuild from 0.8.57 to 0.14.7

[dependabot[bot]]

Bumps esbuild from 0.8.57 to 0.14.7.

Release notes

Sourced from esbuild's releases.

v0.14.7

• Cross-module inlining of TypeScript enum constants (#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:

  // 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 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)

  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:

  // 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)

  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:

... (truncated)

Changelog

Sourced from esbuild's changelog.

0.14.7

• Cross-module inlining of TypeScript enum constants (#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:

  // 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 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)

  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:

  // 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)

  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:

... (truncated)

Commits

• b20e0cc publish 0.14.7 to npm
• 8e551a7 fix #1876: preserve the behavior of the input code
• 6082ad8 recover from unexpected brace at top-level (#1876)
• b52096b cross-module inlining of ts enum constants (#128)
• 169d938 compress boolean flags on records
• 434bbc6 fix #705: mark node built-ins as side-effect free
• e39dd7a update go 1.17.4 => 1.17.5
• 1baacc8 publish 0.14.6 to npm
• c3182c4 fix bugs introduced by #1859
• f780076 fix(parser): allow Identifier keyof, readonly, infer in TypeScriptObjec...
• Additional commits viewable in compare view

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

---

Dependabot commands and options

You can trigger Dependabot actions by commenting on this PR: - `@dependabot rebase` will rebase this PR - `@dependabot recreate` will recreate this PR, overwriting any edits that have been made to it - `@dependabot merge` will merge this PR after your CI passes on it - `@dependabot squash and merge` will squash and merge this PR after your CI passes on it - `@dependabot cancel merge` will cancel a previously requested merge and block automerging - `@dependabot reopen` will reopen this PR if it is closed - `@dependabot close` will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually - `@dependabot ignore this major version` will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself) - `@dependabot ignore this minor version` will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself) - `@dependabot ignore this dependency` will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)

[dependabot[bot]]

Superseded by #109.