Bump esbuild from 0.14.8 to 0.14.9

[dependabot]

Bumps esbuild from 0.14.8 to 0.14.9.

Release notes

Sourced from esbuild's releases.

v0.14.9

• Implement cross-module tree shaking of TypeScript enum values (#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:

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

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

  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)

  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:

  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 }
      ╵ ~~~~~~
  
  

... (truncated)

Changelog

Sourced from esbuild's changelog.

0.14.9

• Implement cross-module tree shaking of TypeScript enum values (#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:

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

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

  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)

  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:

  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 }
  
  

... (truncated)

Commits

• 59e65e0 publish 0.14.9 to npm
• b536d34 make the check from #1887 more conservative
• c8781b5 fix #128: cross-module tree shaking of ts enums
• 989f03e move dependency construction from parser to linker
• e873959 fix #1890: regression due to lack of "__toESM()"
• fccd1c4 iife minification rules
• 187fb30 ts: optimize minified namespace/enum size slightly
• cd8a10a disable max paragraph width for certain notes
• b4bd8b3 fix #1887: warn about "module" or "exports" in esm
• 74b4aa6 make esm detection more consistent
• 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)