Bump esbuild from 0.11.7 to 0.13.3

[dependabot]

Bumps esbuild from 0.11.7 to 0.13.3.

Release notes

Sourced from esbuild's releases.

v0.13.3

• Support TypeScript type-only import/export specifiers (#1637)

  This release adds support for a new TypeScript syntax feature in the upcoming version 4.5 of TypeScript. This feature lets you prefix individual imports and exports with the type keyword to indicate that they are types instead of values. This helps tools such as esbuild omit them from your source code, and is necessary because esbuild compiles files one-at-a-time and doesn't know at parse time which imports/exports are types and which are values. The new syntax looks like this:

  // Input TypeScript code
  import { type Foo } from 'foo'
  export { type Bar }
  // Output JavaScript code (requires "importsNotUsedAsValues": "preserve" in "tsconfig.json")
  import {} from "foo";
  export {};

  See microsoft/TypeScript#45998 for full details. From what I understand this is a purely ergonomic improvement since this was already previously possible using a type-only import/export statements like this:

  // Input TypeScript code
  import type { Foo } from 'foo'
  export type { Bar }
  import 'foo'
  export {}
  // Output JavaScript code (requires "importsNotUsedAsValues": "preserve" in "tsconfig.json")
  import "foo";
  export {};

  This feature was contributed by @​g-plane.

v0.13.2

• Fix export {} statements with --tree-shaking=true (#1628)

  The new --tree-shaking=true option allows you to force-enable tree shaking in cases where it wasn't previously possible. One such case is when bundling is disabled and there is no output format configured, in which case esbuild just preserves the format of whatever format the input code is in. Enabling tree shaking in this context caused a bug where export {} statements were stripped. This release fixes the bug so export {} statements should now be preserved when you pass --tree-shaking=true. This bug only affected this new functionality and didn't affect existing scenarios.

v0.13.1

• Fix the esbuild package in yarn 2+

  The yarn package manager version 2 and above has a mode called PnP that installs packages inside zip files instead of using individual files on disk, and then hijacks node's fs module to pretend that paths to files inside the zip file are actually individual files on disk so that code that wasn't written specifically for yarn still works. Unfortunately that hijacking is incomplete and it still causes certain things to break such as using these zip file paths to create a JavaScript worker thread or to create a child process.

  This was an issue for the new optionalDependencies package installation strategy that was just released in version 0.13.0 since the binary executable is now inside of an installed package instead of being downloaded using an install script. When it's installed with yarn 2+ in PnP mode the binary executable is inside a zip file and can't be run. To work around this, esbuild detects yarn's PnP mode and copies the binary executable to a real file outside of the zip file.

  Unfortunately the code to do this didn't create the parent directory before writing to the file path. That caused esbuild's API to crash when it was run for the first time. This didn't come up during testing because the parent directory already existed when the tests were run. This release changes the location of the binary executable from a shared cache directory to inside the esbuild package itself, which should fix this crash. This problem only affected esbuild's JS API when it was run through yarn 2+ with PnP mode active.

v0.13.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). 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.12.0. See the documentation about semver for more information.

• Allow tree shaking to be force-enabled and force-disabled (#1518, #1610, #1611, #1617)

... (truncated)

Changelog

Sourced from esbuild's changelog.

0.13.3

• Support TypeScript type-only import/export specifiers (#1637)

  This release adds support for a new TypeScript syntax feature in the upcoming version 4.5 of TypeScript. This feature lets you prefix individual imports and exports with the type keyword to indicate that they are types instead of values. This helps tools such as esbuild omit them from your source code, and is necessary because esbuild compiles files one-at-a-time and doesn't know at parse time which imports/exports are types and which are values. The new syntax looks like this:

  // Input TypeScript code
  import { type Foo } from 'foo'
  export { type Bar }
  // Output JavaScript code (requires "importsNotUsedAsValues": "preserve" in "tsconfig.json")
  import {} from "foo";
  export {};

  See microsoft/TypeScript#45998 for full details. From what I understand this is a purely ergonomic improvement since this was already previously possible using a type-only import/export statements like this:

  // Input TypeScript code
  import type { Foo } from 'foo'
  export type { Bar }
  import 'foo'
  export {}
  // Output JavaScript code (requires "importsNotUsedAsValues": "preserve" in "tsconfig.json")
  import "foo";
  export {};

  This feature was contributed by @​g-plane.

0.13.2

• Fix export {} statements with --tree-shaking=true (#1628)

  The new --tree-shaking=true option allows you to force-enable tree shaking in cases where it wasn't previously possible. One such case is when bundling is disabled and there is no output format configured, in which case esbuild just preserves the format of whatever format the input code is in. Enabling tree shaking in this context caused a bug where export {} statements were stripped. This release fixes the bug so export {} statements should now be preserved when you pass --tree-shaking=true. This bug only affected this new functionality and didn't affect existing scenarios.

0.13.1

• Fix the esbuild package in yarn 2+

  The yarn package manager version 2 and above has a mode called PnP that installs packages inside zip files instead of using individual files on disk, and then hijacks node's fs module to pretend that paths to files inside the zip file are actually individual files on disk so that code that wasn't written specifically for yarn still works. Unfortunately that hijacking is incomplete and it still causes certain things to break such as using these zip file paths to create a JavaScript worker thread or to create a child process.

  This was an issue for the new optionalDependencies package installation strategy that was just released in version 0.13.0 since the binary executable is now inside of an installed package instead of being downloaded using an install script. When it's installed with yarn 2+ in PnP mode the binary executable is inside a zip file and can't be run. To work around this, esbuild detects yarn's PnP mode and copies the binary executable to a real file outside of the zip file.

  Unfortunately the code to do this didn't create the parent directory before writing to the file path. That caused esbuild's API to crash when it was run for the first time. This didn't come up during testing because the parent directory already existed when the tests were run. This release changes the location of the binary executable from a shared cache directory to inside the esbuild package itself, which should fix this crash. This problem only affected esbuild's JS API when it was run through yarn 2+ with PnP mode active.

0.13.0

... (truncated)

Commits

• 78e0468 publish 0.13.3 to npm
• 4f42587 support type-only import/export specifiers (#1637)
• 4adbb29 add "preferUnplugged: false" to binary packages
• 2105a17 publish 0.13.2 to npm
• b806837 fix cache condition in iswin_wasm (#1630)
• 67ce58c fix #1628: "export {}" with "--tree-shaking=true"
• 29e8f9d publish 0.13.1 to npm
• 583569e yarn pnp compat: copy binary into the current pkg
• 98b0640 fix the "esbuild" package in yarn 2+
• 80fbcc9 fix release gh action to ignore nested headers
• 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)

[vercel]

This pull request is being automatically deployed with Vercel (learn more).
To see the status of your deployment, click below or on the icon next to each commit.

🔍 Inspect: https://vercel.com/monkatraz/mainframe/3R47g4ouhcy3aWiq8kpwYWRFCejG
✅ Preview: https://mainframe-git-dependabot-npmandyarnesbuild-0133-monkatraz.vercel.app