build: bump esbuild from 0.14.12 to 0.14.13

[dependabot]

Bumps esbuild from 0.14.12 to 0.14.13.

Release notes

Sourced from esbuild's releases.

v0.14.13

• Be more consistent about external paths (#619)

  The rules for marking paths as external using --external: grew over time as more special-cases were added. This release reworks the internal representation to be more straightforward and robust. A side effect is that wildcard patterns can now match post-resolve paths in addition to pre-resolve paths. Specifically you can now do --external:./node_modules/* to mark all files in the ./node_modules/ directory as external.

  This is the updated logic:

  • Before path resolution begins, import paths are checked against everything passed via an --external: flag. In addition, if something looks like a package path (i.e. doesn't start with / or ./ or ../), import paths are checked to see if they have that package path as a path prefix (so --external:@foo/bar matches the import path @foo/bar/baz).

  • After path resolution ends, the absolute paths are checked against everything passed via --external: that doesn't look like a package path (i.e. that starts with / or ./ or ../). But before checking, the pattern is transformed to be relative to the current working directory.

• Attempt to explain why esbuild can't run (#1819)

  People sometimes try to install esbuild on one OS and then copy the node_modules directory over to another OS without reinstalling. This works with JavaScript code but doesn't work with esbuild because esbuild is a native binary executable. This release attempts to offer a helpful error message when this happens. It looks like this:

  $ ./node_modules/.bin/esbuild
  ./node_modules/esbuild/bin/esbuild:106
            throw new Error(`
            ^
  Error:
  You installed esbuild on another platform than the one you're currently using.
  This won't work because esbuild is written with native code and needs to
  install a platform-specific binary executable.
  Specifically the "esbuild-linux-arm64" package is present but this platform
  needs the "esbuild-darwin-arm64" package instead. People often get into this
  situation by installing esbuild on Windows or macOS and copying "node_modules"
  into a Docker image that runs Linux, or by copying "node_modules" between
  Windows and WSL environments.
  If you are installing with npm, you can try not copying the "node_modules"
  directory when you copy the files over, and running "npm ci" or "npm install"
  on the destination platform after the copy. Or you could consider using yarn
  instead which has built-in support for installing a package on multiple
  platforms simultaneously.
  If you are installing with yarn, you can try listing both this platform and the
  other platform in your ".yarnrc.yml" file using the "supportedArchitectures"
  feature: https://yarnpkg.com/configuration/yarnrc/#supportedArchitectures
  Keep in mind that this means multiple copies of esbuild will be present.
  Another alternative is to use the "esbuild-wasm" package instead, which works
  the same way on all platforms. But it comes with a heavy performance cost and
  can sometimes be 10x slower than the "esbuild" package, so you may also not
  want to do that.
  at generateBinPath (./node_modules/esbuild/bin/esbuild:106:17)
  at Object.<anonymous> (./node_modules/esbuild/bin/esbuild:161:39)
  
  

... (truncated)

Changelog

Sourced from esbuild's changelog.

0.14.13

• Be more consistent about external paths (#619)

  The rules for marking paths as external using --external: grew over time as more special-cases were added. This release reworks the internal representation to be more straightforward and robust. A side effect is that wildcard patterns can now match post-resolve paths in addition to pre-resolve paths. Specifically you can now do --external:./node_modules/* to mark all files in the ./node_modules/ directory as external.

  This is the updated logic:

  • Before path resolution begins, import paths are checked against everything passed via an --external: flag. In addition, if something looks like a package path (i.e. doesn't start with / or ./ or ../), import paths are checked to see if they have that package path as a path prefix (so --external:@foo/bar matches the import path @foo/bar/baz).

  • After path resolution ends, the absolute paths are checked against everything passed via --external: that doesn't look like a package path (i.e. that starts with / or ./ or ../). But before checking, the pattern is transformed to be relative to the current working directory.

• Attempt to explain why esbuild can't run (#1819)

  People sometimes try to install esbuild on one OS and then copy the node_modules directory over to another OS without reinstalling. This works with JavaScript code but doesn't work with esbuild because esbuild is a native binary executable. This release attempts to offer a helpful error message when this happens. It looks like this:

  $ ./node_modules/.bin/esbuild
  ./node_modules/esbuild/bin/esbuild:106
            throw new Error(`
            ^
  Error:
  You installed esbuild on another platform than the one you're currently using.
  This won't work because esbuild is written with native code and needs to
  install a platform-specific binary executable.
  Specifically the "esbuild-linux-arm64" package is present but this platform
  needs the "esbuild-darwin-arm64" package instead. People often get into this
  situation by installing esbuild on Windows or macOS and copying "node_modules"
  into a Docker image that runs Linux, or by copying "node_modules" between
  Windows and WSL environments.
  If you are installing with npm, you can try not copying the "node_modules"
  directory when you copy the files over, and running "npm ci" or "npm install"
  on the destination platform after the copy. Or you could consider using yarn
  instead which has built-in support for installing a package on multiple
  platforms simultaneously.
  If you are installing with yarn, you can try listing both this platform and the
  other platform in your ".yarnrc.yml" file using the "supportedArchitectures"
  feature: https://yarnpkg.com/configuration/yarnrc/#supportedArchitectures
  Keep in mind that this means multiple copies of esbuild will be present.
  Another alternative is to use the "esbuild-wasm" package instead, which works
  the same way on all platforms. But it comes with a heavy performance cost and
  can sometimes be 10x slower than the "esbuild" package, so you may also not
  want to do that.
  at generateBinPath (./node_modules/esbuild/bin/esbuild:106:17)
  
  

... (truncated)

Commits

• 98060a2 publish 0.14.13 to npm
• 639ff15 fix post-resolved external patterns
• 345f64c fix #619: make --external: more consistent
• 572240c remove an unused type
• 3449be5 attempt a better x-platform error message (#1819)
• 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 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)

[codecov-commenter]

Codecov Report

Merging #56 (b3144e9) into master (585d893) will not change coverage.
The diff coverage is n/a.

@@            Coverage Diff            @@
##            master       #56   +/-   ##
=========================================
  Coverage   100.00%   100.00%           
=========================================
  Files            2         2           
  Lines           48        48           
  Branches        10        10           
=========================================
  Hits            48        48           

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 76ab92a...b3144e9. Read the comment docs.

[dependabot]

Superseded by #58.