Bump esbuild from 0.8.54 to 0.14.1

[dependabot[bot]]

Bumps esbuild from 0.8.54 to 0.14.1.

Release notes

Sourced from esbuild's releases.

v0.14.1

• Fix imports in package.json (#1807)

  This release contains a fix for the rarely-used imports feature in package.json files that lets a package specify a custom remapping for import paths inside that package that start with #. Support for imports was added in version 0.13.9. However, the field was being incorrectly interpreted as relative to the importing file instead of to the package.json file, which caused an import failure when the importing file is in a subdirectory instead of being at the top level of the package. Import paths should now be interpreted as relative to the correct directory which should fix these path resolution failures.

• Isolate implicit sibling scope lookup for enum and namespace

  The previous release implemented sibling namespaces in TypeScript, which introduces a new kind of scope lookup that doesn't exist in JavaScript. Exported members inside an enum or namespace block can be implicitly referenced in a sibling enum or namespace block just by using the name without using a property reference. However, this behavior appears to only work for enum-to-enum and namespace-to-namespace interactions. Even though sibling enums and namespaces with the same name can be merged together into the same underlying object, this implicit reference behavior doesn't work for enum-to-namespace interactions and attempting to do this with a namespace-to-enum interaction causes the TypeScript compiler itself to crash. Here is an example of how the TypeScript compiler behaves in each case:

  // "b" is accessible
  enum a { b = 1 }
  enum a { c = b }
  // "e" is accessible
  namespace d { export let e = 1 }
  namespace d { export let f = e }
  // "h" is inaccessible
  enum g { h = 1 }
  namespace g { export let i = h }
  // This causes the TypeScript compiler to crash
  namespace j { export let k = 1 }
  enum j { l = k }
  

  This release changes the implicit sibling scope lookup behavior to only work for enum-to-enum and namespace-to-namespace interactions. These implicit references no longer work with enum-to-namespace and namespace-to-enum interactions, which should more accurately match the behavior of the TypeScript compiler.

• Add semicolon insertion before TypeScript-specific definite assignment assertion modifier (#1810)

  TypeScript lets you add a ! after a variable declaration to bypass TypeScript's definite assignment analysis:

  let x!: number[];
  initialize();
  x.push(4);
  function initialize() { x = [0, 1, 2, 3]; }
  

  This ! is called a definite assignment assertion and tells TypeScript to assume that the variable has been initialized somehow. However, JavaScript's automatic semicolon insertion rules should be able to insert a semicolon before it:

  let a
  !function(){}()
  

  Previously the above code was incorrectly considered a syntax error in TypeScript. With this release, this code is now parsed correctly.

... (truncated)

Changelog

Sourced from esbuild's changelog.

0.14.1

• Fix imports in package.json (#1807)

  This release contains a fix for the rarely-used imports feature in package.json files that lets a package specify a custom remapping for import paths inside that package that start with #. Support for imports was added in version 0.13.9. However, the field was being incorrectly interpreted as relative to the importing file instead of to the package.json file, which caused an import failure when the importing file is in a subdirectory instead of being at the top level of the package. Import paths should now be interpreted as relative to the correct directory which should fix these path resolution failures.

• Isolate implicit sibling scope lookup for enum and namespace

  The previous release implemented sibling namespaces in TypeScript, which introduces a new kind of scope lookup that doesn't exist in JavaScript. Exported members inside an enum or namespace block can be implicitly referenced in a sibling enum or namespace block just by using the name without using a property reference. However, this behavior appears to only work for enum-to-enum and namespace-to-namespace interactions. Even though sibling enums and namespaces with the same name can be merged together into the same underlying object, this implicit reference behavior doesn't work for enum-to-namespace interactions and attempting to do this with a namespace-to-enum interaction causes the TypeScript compiler itself to crash. Here is an example of how the TypeScript compiler behaves in each case:

  // "b" is accessible
  enum a { b = 1 }
  enum a { c = b }
  // "e" is accessible
  namespace d { export let e = 1 }
  namespace d { export let f = e }
  // "h" is inaccessible
  enum g { h = 1 }
  namespace g { export let i = h }
  // This causes the TypeScript compiler to crash
  namespace j { export let k = 1 }
  enum j { l = k }
  

  This release changes the implicit sibling scope lookup behavior to only work for enum-to-enum and namespace-to-namespace interactions. These implicit references no longer work with enum-to-namespace and namespace-to-enum interactions, which should more accurately match the behavior of the TypeScript compiler.

• Add semicolon insertion before TypeScript-specific definite assignment assertion modifier (#1810)

  TypeScript lets you add a ! after a variable declaration to bypass TypeScript's definite assignment analysis:

  let x!: number[];
  initialize();
  x.push(4);
  function initialize() { x = [0, 1, 2, 3]; }
  

  This ! is called a definite assignment assertion and tells TypeScript to assume that the variable has been initialized somehow. However, JavaScript's automatic semicolon insertion rules should be able to insert a semicolon before it:

  let a
  !function(){}()
  

  Previously the above code was incorrectly considered a syntax error in TypeScript. With this release, this code is now parsed correctly.

... (truncated)

Commits

• 470c38e publish 0.14.1 to npm
• 2586e4f fill out cli error help text
• 55cc071 update the default log limit in the help text
• 90f3449 enable tests that should have been enabled
• cd6c890 default cli log level: 10 => 6
• ab92f87 more error message adjustments
• 63cca7f add a friendly error message for jsx in js
• 9ec5c57 better missing comma errors in enum
• 32b3c36 show inlined enum names as comments
• e1bb432 Overhaul log message formatting (#1811)
• 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 #469.