chore(deps): update all non-major dependencies

[renovate]

This PR contains the following updates:

Package	Change	Age	Adoption	Passing	Confidence
@rollup/plugin-node-resolve	^13.1.3 -> ^13.2.0
@vercel/nft	^0.18.0 -> ^0.18.1
c12	^0.2.4 -> ^0.2.5
esbuild	^0.14.34 -> ^0.14.36
eslint (source)	^8.12.0 -> ^8.13.0
h3	^0.7.1 -> ^0.7.2
listhen	^0.2.6 -> ^0.2.8
vitest	^0.9.0 -> ^0.9.3
yarn	3.1.1 -> 3.2.0

---

Release Notes

rollup/plugins

v13.2.0

2022-04-11

Features

• feat: Add the ability to pass a function into resolveOnly (#​1152)

vercel/nft

v0.18.1

Compare Source

Patches

• Chore: replace deprecated String.prototype.substr(): #​280
• Fix: add pixelmatch to special case list: #​281

Credits

Huge thanks to @​CommanderRoot for helping!

unjs/c12

v0.2.5

Compare Source

evanw/esbuild

v0.14.36

Compare Source

• Revert path metadata validation for now (#​2177)

  This release reverts the path metadata validation that was introduced in the previous release. This validation has uncovered a potential issue with how esbuild handles onResolve callbacks in plugins that will need to be fixed before path metadata validation is re-enabled.

v0.14.35

Compare Source

• Add support for parsing typeof on #private fields from TypeScript 4.7 (#​2174)

  The upcoming version of TypeScript now lets you use #private fields in typeof type expressions:

  https://devblogs.microsoft.com/typescript/announcing-typescript-4-7-beta/#typeof-on-private-fields

  class Container {
    #data = "hello!";
  
    get data(): typeof this.#data {
      return this.#data;
    }
  
    set data(value: typeof this.#data) {
      this.#data = value;
    }
  }

  With this release, esbuild can now parse these new type expressions as well. This feature was contributed by @​magic-akari.

• Add Opera and IE to internal CSS feature support matrix (#​2170)

  Version 0.14.18 of esbuild added Opera and IE as available target environments, and added them to the internal JS feature support matrix. CSS feature support was overlooked, however. This release adds knowledge of Opera and IE to esbuild's internal CSS feature support matrix:

  /* Original input */
  a {
    color: rgba(0, 0, 0, 0.5);
  }
  
  /* Old output (with --target=opera49 --minify) */
  a{color:rgba(0,0,0,.5)}
  
  /* New output (with --target=opera49 --minify) */
  a{color:#​00000080}

  The fix for this issue was contributed by @​sapphi-red.

• Change TypeScript class field behavior when targeting ES2022

  TypeScript 4.3 introduced a breaking change where class field behavior changes from assign semantics to define semantics when the target setting in tsconfig.json is set to ESNext. Specifically, the default value for TypeScript's useDefineForClassFields setting when unspecified is true if and only if target is ESNext. TypeScript 4.6 introduced another change where this behavior now happens for both ESNext and ES2022. Presumably this will be the case for ES2023 and up as well. With this release, esbuild's behavior has also been changed to match. Now configuring esbuild with --target=es2022 will also cause TypeScript files to use the new class field behavior.

• Validate that path metadata returned by plugins is consistent

  The plugin API assumes that all metadata for the same path returned by a plugin's onResolve callback is consistent. Previously this assumption was just assumed without any enforcement. Starting with this release, esbuild will now enforce this by generating a build error if this assumption is violated. The lack of validation has not been an issue (I have never heard of this being a problem), but it still seems like a good idea to enforce it. Here's a simple example of a plugin that generates inconsistent sideEffects metadata:

  let buggyPlugin = {
    name: 'buggy',
    setup(build) {
      let count = 0
      build.onResolve({ filter: /^react$/ }, args => {
        return {
          path: require.resolve(args.path),
          sideEffects: count++ > 0,
        }
      })
    },
  }

  Since esbuild processes everything in parallel, the set of metadata that ends up being used for a given path is essentially random since it's whatever the task scheduler decides to schedule first. Thus if a plugin does not consistently provide the same metadata for a given path, subsequent builds may return different results. This new validation check prevents this problem.

  Here's the new error message that's shown when this happens:

  ✘ [ERROR] [plugin buggy] Detected inconsistent metadata for the path "node_modules/react/index.js" when it was imported here:
  
      button.tsx:1:30:
        1 │ import { createElement } from 'react'
          ╵                               ~~~~~~~
  
    The original metadata for that path comes from when it was imported here:
  
      app.tsx:1:23:
        1 │ import * as React from 'react'
          ╵                        ~~~~~~~
  
    The difference in metadata is displayed below:
  
     {
    -  "sideEffects": true,
    +  "sideEffects": false,
     }
  
    This is a bug in the "buggy" plugin. Plugins provide metadata for a given path in an "onResolve"
    callback. All metadata provided for the same path must be consistent to ensure deterministic
    builds. Due to parallelism, one set of provided metadata will be randomly chosen for a given path,
    so providing inconsistent metadata for the same path can cause non-determinism.
  

• Suggest enabling a missing condition when exports map fails (#​2163)

  This release adds another suggestion to the error message that happens when an exports map lookup fails if the failure could potentially be fixed by adding a missing condition. Here's what the new error message looks like (which now suggests --conditions=module as a possible workaround):

  ✘ [ERROR] Could not resolve "@​sentry/electron/main"
  
      index.js:1:24:
        1 │ import * as Sentry from '@​sentry/electron/main'
          ╵                         ~~~~~~~~~~~~~~~~~~~~~~~
  
    The path "./main" is not currently exported by package "@​sentry/electron":
  
      node_modules/@​sentry/electron/package.json:8:13:
        8 │   "exports": {
          ╵              ^
  
    None of the conditions provided ("require", "module") match any of the currently active conditions
    ("browser", "default", "import"):
  
      node_modules/@​sentry/electron/package.json:16:14:
        16 │     "./main": {
           ╵               ^
  
    Consider enabling the "module" condition if this package expects it to be enabled. You can use
    "--conditions=module" to do that:
  
      node_modules/@​sentry/electron/package.json:18:6:
        18 │       "module": "./esm/main/index.js"
           ╵       ~~~~~~~~
  
    Consider using a "require()" call to import this file, which will work because the "require"
    condition is supported by this package:
  
      index.js:1:24:
        1 │ import * as Sentry from '@​sentry/electron/main'
          ╵                         ~~~~~~~~~~~~~~~~~~~~~~~
  
    You can mark the path "@​sentry/electron/main" as external to exclude it from the bundle, which
    will remove this error.
  

  This particular package had an issue where it was using the Webpack-specific module condition without providing a default condition. It looks like the intent in this case was to use the standard import condition instead. This specific change wasn't suggested here because this error message is for package consumers, not package authors.

eslint/eslint

v8.13.0

Compare Source

Features

• 274acbd feat: fix no-eval logic for this in arrow functions (#​15755) (Milos Djermanovic)

Bug Fixes

• 97b57ae fix: invalid operator in operator-assignment messages (#​15759) (Milos Djermanovic)

Documentation

• c32482e docs: Typo in space-infix-ops docs (#​15754) (kmin-jeong)
• f2c2d35 docs: disambiguate types FormatterFunction and LoadedFormatter (#​15727) (Francesco Trotta)

Chores

• bb4c0d5 chore: Refactor docs to work with docs.eslint.org (#​15744) (Nicholas C. Zakas)
• d36f12f chore: remove lib/init from eslint config (#​15748) (Milos Djermanovic)
• a59a4e6 chore: replace trimLeft/trimRight with trimStart/trimEnd (#​15750) (Milos Djermanovic)

vitest-dev/vitest

v0.9.3

Compare Source

Bug Fixes

• add vite-node to root dev script (#​1129) (5f53680)
• always show filters, when no tests found (#​1124) (ce53037)
• Issue Template docs link (#​1128) (03aff85)
• respect clearScreen option in vite, close #​1125 (d482992)

v0.9.2

Compare Source

v0.9.1

Compare Source

Bug Fixes

• displayDiff with non-string (61fbddb)
• make automocking aware of symbol indexed methods (#​1119) (06faf8a)
• re-export mock types (#​1120) (45ef020)

Features

• ui: fix file error + add colored support (#​1108) (b737476)
• extend config.outputFile to allow objects, close #​1068 (#​1073) (a63cfa2)

yarnpkg/berry

v3.2.0

Compare Source

Various improvements have been made in the core to improve performance. Additionally:

Commands

• The yarn workspaces foreach run command is now able to run binaries.
• The yarn npm info command now supports displaying information about a tagged version of a package (e.g. yarn npm info vue@next).
• A new yarn explain command has been added. It can be used to explain an error code, or list all available error codes.
  • For example, try to run yarn explain YN0002.
• The yarn npm publish command now accepts a new --otp option, to set the One-Time Password from the CLI.
  • A better error message will also be shown when a query fails due to an invalid OTP.
• yarn upgrade-interactive now has improved paging:
  • Yarn will display as many suggestions as can fit in the viewport (rather than a fixed-size list).
  • The suggestions that fit in the viewport will be fetched in the foreground and will load one-by-one.
  • The suggestions that don't will be fetched in the background and will be loaded in batches to increase responsiveness and reduce input lag.
  • Most notably, you won't have to wait for all of the suggestions to be fetched (which took a very long time before on large monorepos) before you can start navigating through the list.

Installs

• The node-modules linker now tolerates if node_modules is a symbolic link, and doesn't recreate it.
• On top of the cpu and arch fields, Yarn now support a new libc field which can be used in tandem with optionalDependencies to avoid downloading packages that have been linked against incompatible standard libraries (we currently support two values: glibc and musl).
• The pnpm linker has received various improvements:
  • It will now remove the node_modules/.store and node_modules folders if they are empty.
  • It now supports running binaries of soft links.
  • It will now create self-references for packages that don't depend on other versions of themselves.
  • It will now remove scope folders (e.g. node_modules/@​yarnpkg) if they are empty or after removing a scoped dependency.
• All .pnp.cjs files with inlined data will now store the data in a JSON string literal instead of an object literal to improve startup performance.

Compatibility

• The shell now treats backslashes same as Bash (so it mostly ignore them).
  • Could potentially be a breaking change, but the old behavior caused portability issues with a few packages, so we had to make this change (especially since the portable shell is intended to help portability).
• The shell now supports ${FOO:+}.
• The PnP filesystem now handles read and readSync using options.
• The PnP filesystem now handles UNC paths using forward slashes.
• The PnP filesystem now sets the proper path property on streams created by createReadStream() and obtained from zip archives.
• The PnP runtime now throws an ERR_REQUIRE_ESM error when attempting to require an ES Module, matching the default Node.js behaviour.
• Updates the PnP compatibility layer for TypeScript 4.6 Beta (it's possible we'll need to publish another patch update once the 4.6 enters stable).

Bugfixes

• @yarnpkg/pnpify now escapes paths correctly.
• The ESM loader is now enabled regardless of the entrypoint module type, this fixes support for dynamic imports in commonjs modules when the entrypoint is also commonjs.
• The ESM loader is now able to resolve relative imports with search parameters.
• The node field inside the npm_config_user_agent Yarn sets will now include a leading v.
• Yarn is now able to recover from a corrupted install state.
• Yarn is now able to migrate classic lockfiles containing unconventional tarball URLs.
• The nm linker hoists portals after hoisting their dependencies first.
• Fixed a crash caused by a bad interaction between aliased packages and peer dependencies.
• The ESBuild plugin will no longer allow access to Node.js builtins if the platform isn't set to Node.
• SemVer ranges with build metadata can now be resolved.
• The YARN_IGNORE_NODE environment variable will now be parsed using the same mechanism as env variable configuration settings (i.e. both 1/0 and true/false will be accepted)

ZipFS Extension

• You can now unmount zip folders by right-clicking on their workspaces.

Miscellaneous Features

• Reporting for Git errors has been improved.
• The resolution step now has a progress indicator.
• The experimental ESM loader warning emitted by Node.js is now suppressed.
• Private registries can now be authenticated using private keys and certificates.
• A new wrapNetworkRequest hook now lets you wrap network requests (for example to log them).

---

Configuration

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

🚦 Automerge: Disabled by config. Please merge this manually once you are satisfied.

♻ Rebasing: Renovate will not automatically rebase this PR, because other commits have been found.

👻 Immortal: This PR will be recreated if closed unmerged. Get config help if that's undesired.

---

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

---

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

[cloudflare-workers-and-pages]

Deploying with    Cloudflare Pages

Latest commit:	f126cbf
Status:	✅  Deploy successful!
Preview URL:	https://be2693f0.nitropack.pages.dev

View logs