Bump esbuild from 0.12.24 to 0.14.39

[dependabot]

Bumps esbuild from 0.12.24 to 0.14.39.

Release notes

Sourced from esbuild's releases.

v0.14.39

• Fix code generation for export default and /* @__PURE__ */ call (#2203)

  The /* @__PURE__ */ comment annotation can be added to function calls to indicate that they are side-effect free. These annotations are passed through into the output by esbuild since many JavaScript tools understand them. However, there was an edge case where printing this comment before a function call caused esbuild to fail to parenthesize a function literal because it thought it was no longer at the start of the expression. This problem has been fixed:

  // Original code
  export default /* @__PURE__ */ (function() {
  })()
  // Old output
  export default /* @PURE */ function() {
  }();
  // New output
  export default /* @PURE */ (function() {
  })();

• Preserve ... before JSX child expressions (#2245)

  TypeScript 4.5 changed how JSX child expressions that start with ... are emitted. Previously the ... was omitted but starting with TypeScript 4.5, the ... is now preserved instead. This release updates esbuild to match TypeScript's new output in this case:

  // Original code
  console.log(<a>{...b}</a>)
  // Old output
  console.log(/* @PURE */ React.createElement("a", null, b));
  // New output
  console.log(/* @PURE */ React.createElement("a", null, ...b));

  Note that this behavior is TypeScript-specific. Babel doesn't support the ... token at all (it gives the error "Spread children are not supported in React").

• Slightly adjust esbuild's handling of the browser field in package.json (#2239)

  This release changes esbuild's interpretation of browser path remapping to fix a regression that was introduced in esbuild version 0.14.21. Browserify has a bug where it incorrectly matches package paths to relative paths in the browser field, and esbuild replicates this bug for compatibility with Browserify. I have a set of tests that I use to verify that esbuild's replication of this Browserify is accurate here: https://github.com/evanw/package-json-browser-tests. However, I was missing a test case and esbuild's behavior diverges from Browserify in this case. This release now handles this edge case as well:

  • entry.js:

    require('pkg/sub')

  • node_modules/pkg/package.json:

    {

... (truncated)

Changelog

Sourced from esbuild's changelog.

0.14.39

• Fix code generation for export default and /* @__PURE__ */ call (#2203)

  The /* @__PURE__ */ comment annotation can be added to function calls to indicate that they are side-effect free. These annotations are passed through into the output by esbuild since many JavaScript tools understand them. However, there was an edge case where printing this comment before a function call caused esbuild to fail to parenthesize a function literal because it thought it was no longer at the start of the expression. This problem has been fixed:

  // Original code
  export default /* @__PURE__ */ (function() {
  })()
  // Old output
  export default /* @PURE */ function() {
  }();
  // New output
  export default /* @PURE */ (function() {
  })();

• Preserve ... before JSX child expressions (#2245)

  TypeScript 4.5 changed how JSX child expressions that start with ... are emitted. Previously the ... was omitted but starting with TypeScript 4.5, the ... is now preserved instead. This release updates esbuild to match TypeScript's new output in this case:

  // Original code
  console.log(<a>{...b}</a>)
  // Old output
  console.log(/* @PURE */ React.createElement("a", null, b));
  // New output
  console.log(/* @PURE */ React.createElement("a", null, ...b));

  Note that this behavior is TypeScript-specific. Babel doesn't support the ... token at all (it gives the error "Spread children are not supported in React").

• Slightly adjust esbuild's handling of the browser field in package.json (#2239)

  This release changes esbuild's interpretation of browser path remapping to fix a regression that was introduced in esbuild version 0.14.21. Browserify has a bug where it incorrectly matches package paths to relative paths in the browser field, and esbuild replicates this bug for compatibility with Browserify. I have a set of tests that I use to verify that esbuild's replication of this Browserify is accurate here: https://github.com/evanw/package-json-browser-tests. However, I was missing a test case and esbuild's behavior diverges from Browserify in this case. This release now handles this edge case as well:

  • entry.js:

    require('pkg/sub')

  • node_modules/pkg/package.json:

... (truncated)

Commits

• 7abb7d8 publish 0.14.39 to npm
• 5082f3e run "make compat-table"
• bb7a0a1 fix #2239: more closely replicate a browserify bug
• 7e2d75c fix #2245: preserve ... before JSX children
• 1bd0094 attempt to fix pnpm in end-to-end checks
• e876856 fix #2203: export default of /* @__PURE__ */
• e9728a6 readme: use new light/dark mode feature
• fc1862d update to go 1.18.1
• e7a9572 publish 0.14.38 to npm
• 1a57168 fix #2201: more ts instantiation expression fixes
• 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]

The following labels could not be found: engineering, dependencies.

[dependabot]

Superseded by #332.