build(deps): bump github.com/evanw/esbuild from 0.8.17 to 0.9.3

[dependabot]

Bumps github.com/evanw/esbuild from 0.8.17 to 0.9.3.

Release notes

Sourced from github.com/evanw/esbuild's releases.

v0.9.3

• Fix path resolution with the exports field for scoped packages

  This release fixes a bug where the exports field in package.json files was not being detected for scoped packages (i.e. packages of the form @scope/pkg-name instead of just pkg-name). The exports field should now be respected for these kinds of packages.

• Improved error message in exports failure case

  Node's new conditional exports feature can be non-intuitive and hard to use. Now that esbuild supports this feature (as of version 0.9.0), you can get into a situation where it's impossible to import a package if the package's exports field in its package.json file isn't configured correctly.

  Previously the error message for this looked like this:

   > entry.js:1:7: error: Could not resolve "jotai" (mark it as external to exclude it from the bundle)
       1 │ import 'jotai'
         ╵        ~~~~~~~
     node_modules/jotai/package.json:16:13: note: The path "." is not exported by "jotai"
      16 │   "exports": {
         ╵              ^
  

  With this release, the error message will now provide additional information about why the package cannot be imported:

   > entry.js:1:7: error: Could not resolve "jotai" (mark it as external to exclude it from the bundle)
       1 │ import 'jotai'
         ╵        ~~~~~~~
     node_modules/jotai/package.json:16:13: note: The path "." is not currently exported by package "jotai"
      16 │   "exports": {
         ╵              ^
     node_modules/jotai/package.json:18:9: note: None of the conditions provided ("module", "require", "types") match any of the currently active conditions ("browser", "default", "import")
      18 │     ".": {
         ╵          ^
     entry.js:1:7: note: Consider using a "require()" call to import this package
       1 │ import 'jotai'
         ╵        ~~~~~~~
  

  In this case, one solution could be import this module using require() since this package provides an export for the require condition. Another solution could be to pass --conditions=module to esbuild since this package provides an export for the module condition (the types condition is likely not valid JavaScript code).

  This problem occurs because this package doesn't provide an import path for ESM code using the import condition and also doesn't provide a fallback import path using the default condition.

• Mention glob syntax in entry point error messages (#976)

  In this release, including a * in the entry point path now causes the failure message to tell you that glob syntax must be expanded first before passing the paths to esbuild. People that hit this are usually converting an existing CLI command to a JavaScript API call and don't know that glob expansion is done by their shell instead of by esbuild. An appropriate fix is to use a library such as glob to expand the glob pattern first before passing the paths to esbuild.

• Raise certain VM versions in the JavaScript feature compatibility table

  JavaScript VM feature compatibility data is derived from this dataset: https://kangax.github.io/compat-table/. The scripts that process the dataset expand the data to include all VM versions that support a given feature (e.g. chrome44, chrome45, chrome46, ...) so esbuild takes the minimum observed version as the first version for which the feature is supported.

  However, some features can have subtests that each check a different aspect of the feature. In this case the desired version is the minimum version within each individual subtest, but the maximum of those versions across all subtests (since esbuild should only use the feature if it works in all cases). Previously esbuild computed the minimum version across all subtests, but now esbuild computes the maximum version across all subtests. This means esbuild will now lower JavaScript syntax in more cases.

... (truncated)

Changelog

Sourced from github.com/evanw/esbuild's changelog.

0.9.3

• Fix path resolution with the exports field for scoped packages

  This release fixes a bug where the exports field in package.json files was not being detected for scoped packages (i.e. packages of the form @scope/pkg-name instead of just pkg-name). The exports field should now be respected for these kinds of packages.

• Improved error message in exports failure case

  Node's new conditional exports feature can be non-intuitive and hard to use. Now that esbuild supports this feature (as of version 0.9.0), you can get into a situation where it's impossible to import a package if the package's exports field in its package.json file isn't configured correctly.

  Previously the error message for this looked like this:

   > entry.js:1:7: error: Could not resolve "jotai" (mark it as external to exclude it from the bundle)
       1 │ import 'jotai'
         ╵        ~~~~~~~
     node_modules/jotai/package.json:16:13: note: The path "." is not exported by "jotai"
      16 │   "exports": {
         ╵              ^
  

  With this release, the error message will now provide additional information about why the package cannot be imported:

   > entry.js:1:7: error: Could not resolve "jotai" (mark it as external to exclude it from the bundle)
       1 │ import 'jotai'
         ╵        ~~~~~~~
     node_modules/jotai/package.json:16:13: note: The path "." is not currently exported by package "jotai"
      16 │   "exports": {
         ╵              ^
     node_modules/jotai/package.json:18:9: note: None of the conditions provided ("module", "require", "types") match any of the currently active conditions ("browser", "default", "import")
      18 │     ".": {
         ╵          ^
     entry.js:1:7: note: Consider using a "require()" call to import this package
       1 │ import 'jotai'
         ╵        ~~~~~~~
  

  In this case, one solution could be import this module using require() since this package provides an export for the require condition. Another solution could be to pass --conditions=module to esbuild since this package provides an export for the module condition (the types condition is likely not valid JavaScript code).

  This problem occurs because this package doesn't provide an import path for ESM code using the import condition and also doesn't provide a fallback import path using the default condition.

• Mention glob syntax in entry point error messages (#976)

  In this release, including a * in the entry point path now causes the failure message to tell you that glob syntax must be expanded first before passing the paths to esbuild. People that hit this are usually converting an existing CLI command to a JavaScript API call and don't know that glob expansion is done by their shell instead of by esbuild. An appropriate fix is to use a library such as glob to expand the glob pattern first before passing the paths to esbuild.

• Raise certain VM versions in the JavaScript feature compatibility table

  JavaScript VM feature compatibility data is derived from this dataset: https://kangax.github.io/compat-table/. The scripts that process the dataset expand the data to include all VM versions that support a given feature (e.g. chrome44, chrome45, chrome46, ...) so esbuild takes the minimum observed version as the first version for which the feature is supported.

... (truncated)

Commits

• 2961bb8 publish 0.9.3 to npm
• 7320a0e utf16 bug in outside-file line/column accounting
• 8a21240 serve tests: 127.0.0.1 to avoid mac firewall popup
• fc77075 fix "exports" path resolution for scoped packages
• 8fcc937 fix comments (#983)
• 51b785f add engine-to-string to compat-table.js
• d943e89 fix #975: add target env to lowering error
• fbdf70d mention glob syntax in entry point errors (#976)
• 29b7c3f compat table: use the maximum across all subtests
• 5e6528d improve "exports" error messages
• 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]

Superseded by #108.

[github-actions]

This pull request has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.