Bump esbuild from 0.14.20 to 0.14.21

[dependabot]

Bumps esbuild from 0.14.20 to 0.14.21.

Release notes

Sourced from esbuild's releases.

v0.14.21

• Handle an additional browser map edge case (#2001, #2002)

  There is a community convention around the browser field in package.json that allows remapping import paths within a package when the package is bundled for use within a browser. There isn't a rigorous definition of how it's supposed to work and every bundler implements it differently. The approach esbuild uses is to try to be "maximally compatible" in that if at least one bundler exhibits a particular behavior regarding the browser map that allows a mapping to work, then esbuild also attempts to make that work.

  I have a collection of test cases for this going here: https://github.com/evanw/package-json-browser-tests. However, I was missing test coverage for the edge case where a package path import in a subdirectory of the package could potentially match a remapping. The "maximally compatible" approach means replicating bugs in Browserify's implementation of the feature where package paths are mistaken for relative paths and are still remapped. Here's a specific example of an edge case that's now handled:

  • entry.js:

    require('pkg/sub')

  • node_modules/pkg/package.json:

    {
      "browser": {
        "./sub": "./sub/foo.js",
        "./sub/sub": "./sub/bar.js"
      }
    }

  • node_modules/pkg/sub/foo.js:

    require('sub')

  • node_modules/pkg/sub/bar.js:

    console.log('works')

  The import path sub in require('sub') is mistaken for a relative path by Browserify due to a bug in Browserify, so Browserify treats it as if it were ./sub instead. This is a Browserify-specific behavior and currently doesn't happen in any other bundler (except for esbuild, which attempts to replicate Browserify's bug).

  Previously esbuild was incorrectly resolving ./sub relative to the top-level package directory instead of to the subdirectory in this case, which meant ./sub was incorrectly matching "./sub": "./sub/foo.js" instead of "./sub/sub": "./sub/bar.js". This has been fixed so esbuild can now emulate Browserify's bug correctly in this edge case.

• Support for esbuild with Linux on RISC-V 64bit (#1624)

  With this release, esbuild now has a published binary executable for the RISC-V 64bit architecture in the esbuild-linux-riscv64 npm package. This change was contributed by @​piggynl.

Changelog

Sourced from esbuild's changelog.

0.14.21

• Handle an additional browser map edge case (#2001, #2002)

  There is a community convention around the browser field in package.json that allows remapping import paths within a package when the package is bundled for use within a browser. There isn't a rigorous definition of how it's supposed to work and every bundler implements it differently. The approach esbuild uses is to try to be "maximally compatible" in that if at least one bundler exhibits a particular behavior regarding the browser map that allows a mapping to work, then esbuild also attempts to make that work.

  I have a collection of test cases for this going here: https://github.com/evanw/package-json-browser-tests. However, I was missing test coverage for the edge case where a package path import in a subdirectory of the package could potentially match a remapping. The "maximally compatible" approach means replicating bugs in Browserify's implementation of the feature where package paths are mistaken for relative paths and are still remapped. Here's a specific example of an edge case that's now handled:

  • entry.js:

    require('pkg/sub')

  • node_modules/pkg/package.json:

    {
      "browser": {
        "./sub": "./sub/foo.js",
        "./sub/sub": "./sub/bar.js"
      }
    }

  • node_modules/pkg/sub/foo.js:

    require('sub')

  • node_modules/pkg/sub/bar.js:

    console.log('works')

  The import path sub in require('sub') is mistaken for a relative path by Browserify due to a bug in Browserify, so Browserify treats it as if it were ./sub instead. This is a Browserify-specific behavior and currently doesn't happen in any other bundler (except for esbuild, which attempts to replicate Browserify's bug).

  Previously esbuild was incorrectly resolving ./sub relative to the top-level package directory instead of to the subdirectory in this case, which meant ./sub was incorrectly matching "./sub": "./sub/foo.js" instead of "./sub/sub": "./sub/bar.js". This has been fixed so esbuild can now emulate Browserify's bug correctly in this edge case.

• Support for esbuild with Linux on RISC-V 64bit (#1624)

  With this release, esbuild now has a published binary executable for the RISC-V 64bit architecture in the esbuild-linux-riscv64 npm package. This change was contributed by @​piggynl.

Commits

• 9d1e47b publish 0.14.21 to npm
• 90a60e0 Update CHANGELOG.md
• 25c6862 close #2001, fix #2002: "browser" map edge case
• ce9b989 update changelog for #2000
• 644ca7d feat: support linux riscv64 LE architecture (#2000)
• 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)