chore(deps-dev): bump esbuild from 0.8.17 to 0.8.19

[dependabot-preview]

Bumps esbuild from 0.8.17 to 0.8.19.

Release notes

Sourced from esbuild's releases.

v0.8.19

• Handle non-ambiguous multi-path re-exports (#568)

  Wildcard re-exports using the export * from 'path' syntax can potentially result in name collisions that cause an export name to be ambiguous. For example, the following code would result in an ambiguous export if both a.js and b.js export a symbol with the same name:

  export * from './a.js'
  export * from './b.js'

  Ambiguous exports have two consequences. First, any ambiguous names are silently excluded from the set of exported names. If you use an import * as wildcard import, the excluded names will not be present. Second, attempting to explicitly import an ambiguous name using an import {} from import clause will result in a module instantiation error.

  This release fixes a bug where esbuild could in certain cases consider a name ambiguous when it actually isn't. Specifically this happens with longer chains of mixed wildcard and named re-exports. Here is one such case:

  // entry.js
  import {x, y} from './not-ambiguous.js'
  console.log(x, y)

  // /not-ambiguous.js
  export * from './a.js'
  export * from './b.js'

  // /a.js
  export * from './c.js'

  // /b.js
  export {x} from './c.js'

  // /c.js
  export let x = 1, y = 2

  Previously bundling entry.js with esbuild would incorrectly generate an error about an ambiguous x export. Now this case builds successfully without an error.

• Omit warnings about non-string paths in await import() inside a try block (#574)

  Bundling code that uses require() or import() with a non-string path currently generates a warning, because the target of that import will not be included in the bundle. This is helpful to warn about because other bundlers handle this case differently (e.g. Webpack bundles the entire directory tree and emulates a file system lookup) so existing code may expect the target of the import to be bundled.

  You can avoid the warning with esbuild by surrounding the call to require() with a try block. The thinking is that if there is a surrounding try block, presumably the code is expecting the require() call to possibly fail and is prepared to handle the error. However, there is currently no way to avoid the warning for import() expressions. This release introduces an analogous behavior for import() expressions. You can now avoid the warning with esbuild if you use await import() and surround it with a try block.

v0.8.18

Changelog

Sourced from esbuild's changelog.

0.8.19

• Handle non-ambiguous multi-path re-exports (#568)

  Wildcard re-exports using the export * from 'path' syntax can potentially result in name collisions that cause an export name to be ambiguous. For example, the following code would result in an ambiguous export if both a.js and b.js export a symbol with the same name:

  export * from './a.js'
  export * from './b.js'

  Ambiguous exports have two consequences. First, any ambiguous names are silently excluded from the set of exported names. If you use an import * as wildcard import, the excluded names will not be present. Second, attempting to explicitly import an ambiguous name using an import {} from import clause will result in a module instantiation error.

  This release fixes a bug where esbuild could in certain cases consider a name ambiguous when it actually isn't. Specifically this happens with longer chains of mixed wildcard and named re-exports. Here is one such case:

  // entry.js
  import {x, y} from './not-ambiguous.js'
  console.log(x, y)

  // /not-ambiguous.js
  export * from './a.js'
  export * from './b.js'

  // /a.js
  export * from './c.js'

  // /b.js
  export {x} from './c.js'

  // /c.js
  export let x = 1, y = 2

  Previously bundling entry.js with esbuild would incorrectly generate an error about an ambiguous x export. Now this case builds successfully without an error.

• Omit warnings about non-string paths in await import() inside a try block (#574)

  Bundling code that uses require() or import() with a non-string path currently generates a warning, because the target of that import will not be included in the bundle. This is helpful to warn about because other bundlers handle this case differently (e.g. Webpack bundles the entire directory tree and emulates a file system lookup) so existing code may expect the target of the import to be bundled.

  You can avoid the warning with esbuild by surrounding the call to require() with a try block. The thinking is that if there is a surrounding try block, presumably the code is expecting the require() call to possibly fail and is prepared to handle the error. However, there is currently no way to avoid the warning for import() expressions. This release introduces an analogous behavior for import() expressions. You can now avoid the warning with esbuild if you use await import() and surround it with a try block.

Commits

• 5934b26 publish 0.8.19 to npm
• 56aac9a more helpful error if rosetta 2 is missing (#564)
• 6be8e44 fix #574: silent "await import()" inside "try"
• b196707 close #568: fix non-ambiguous multi-path imports
• 4438d12 extract import matching to function
• a55da63 use an array to detect import cycles
• 9ed9858 publish 0.8.18 to npm
• 9f5e37e fix #573: nested optional chain edge case
• f00ea5a workaround for windows-only ci issue
• 1f3bd9d fix a renaming bug with external imports
• See full diff 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 badge me will comment on this PR with code to add a "Dependabot enabled" badge to your readme

Additionally, you can set the following in the .dependabot/config.yml file in this repo:

• Update frequency
• Automerge options (never/patch/minor, and dev/runtime dependencies)
• Out-of-range updates (receive only lockfile updates, if desired)
• Security updates (receive only security updates, if desired)

[gitpod-io]

[aws-cdk-automation]

AWS CodeBuild CI Report

• CodeBuild project: AutoBuildProject6AEA49D1-qxepHUsryhcu
• Commit ID: 1215032
• Result: SUCCEEDED
• Build Logs (available for 30 days)

Powered by github-codebuild-logs, available on the AWS Serverless Application Repository

[mergify]

Thanks Dependabot!