Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Update dependency esbuild to v0.14.21 #4427

Merged
merged 1 commit into from Feb 10, 2022
Merged

Update dependency esbuild to v0.14.21 #4427

merged 1 commit into from Feb 10, 2022

Conversation

renovate[bot]
Copy link
Contributor

@renovate renovate bot commented Feb 9, 2022

WhiteSource Renovate

This PR contains the following updates:

Package Change Age Adoption Passing Confidence
esbuild 0.14.20 -> 0.14.21 age adoption passing confidence

Release Notes

evanw/esbuild

v0.14.21

Compare Source

  • 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 (#​2000)

    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.


Configuration

📅 Schedule: At any time (no schedule defined).

🚦 Automerge: Enabled.

Rebasing: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox.

🔕 Ignore: Close this PR and you won't be reminded about this update again.


  • If you want to rebase/retry this PR, click this checkbox.

This PR has been generated by WhiteSource Renovate. View repository job log here.

@renovate renovate bot added the release:chore This PR is a chore (means nothing for users) label Feb 9, 2022
@renovate renovate bot assigned jtoar Feb 9, 2022
@renovate renovate bot force-pushed the renovate/esbuild-0.x branch 2 times, most recently from e05d234 to ca52541 Compare February 9, 2022 21:08
@renovate renovate bot merged commit 00fcb77 into main Feb 10, 2022
@renovate renovate bot deleted the renovate/esbuild-0.x branch February 10, 2022 00:59
@jtoar jtoar added this to the next-release milestone Feb 10, 2022
@thedavidprice thedavidprice modified the milestones: next-release, v0.45.0 Feb 11, 2022
dac09 added a commit to dac09/redwood that referenced this pull request Feb 14, 2022
…bundle

* 'main' of github.com:redwoodjs/redwood: (324 commits)
  (render.com deployment) resolve deploy render exceeding memory on free tier (redwoodjs#4433)
  Update dependency @clerk/types to v1.25.0 (redwoodjs#4419)
  Update dependency esbuild to v0.14.21 (redwoodjs#4427)
  Update dependency @types/prettier to v2.4.4 (redwoodjs#4426)
  Update dependency @envelop/depth-limit to v1.2.3 (redwoodjs#4428)
  Support enums when scaffolding modes to display values and generate form inputs (redwoodjs#4395)
  Update dependency @clerk/clerk-js to v2.13.1 (redwoodjs#4418)
  Update jest monorepo to v27.5.1 (redwoodjs#4421)
  Update dependency @types/md5 to v2.3.2 (redwoodjs#4420)
  Polish release script (redwoodjs#4417)
  Update dependency @azure/msal-browser to v2.22.0 (redwoodjs#4414)
  Update dependency fastify-http-proxy to v6.2.2 (redwoodjs#4413)
  Roll back dependency @magic-sdk/admin to 1.3.4 (redwoodjs#4409)
  update yarn.lock
  Update typescript-eslint monorepo to v5.11.0 (redwoodjs#4412)
  v0.44.1
  Downgrade Prisma to 3.8.1 (redwoodjs#4411)
  Downgrade Prisma to 3.8.1 (redwoodjs#4411)
  update yarn.lock
  fix(generators): Generate types after gen-ing files (redwoodjs#4376)
  ...
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
release:chore This PR is a chore (means nothing for users)
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants