build: update all non-major dependencies

[renovate]

This PR contains the following updates:

Package	Change	Age	Adoption	Passing	Confidence
ajv (source)	8.8.1 -> 8.8.2
esbuild	0.13.14 -> 0.13.15
esbuild-wasm	0.13.14 -> 0.13.15
eslint (source)	8.2.0 -> 8.3.0
webpack	5.64.1 -> 5.64.2

---

Release Notes

ajv-validator/ajv

v8.8.2

Compare Source

Use full RegExp string (with flags) as cache key, related to https://github.com/ajv-validator/ajv-keywords/issues/220

evanw/esbuild

v0.13.15

Compare Source

• Fix super in lowered async arrow functions (#​1777)

  This release fixes an edge case that was missed when lowering async arrow functions containing super property accesses for compile targets that don't support async such as with --target=es6. The problem was that lowering transforms async arrow functions into generator function expressions that are then passed to an esbuild helper function called __async that implements the async state machine behavior. Since function expressions do not capture this and super like arrow functions do, this led to a mismatch in behavior which meant that the transform was incorrect. The fix is to introduce a helper function to forward super access into the generator function expression body. Here's an example:

  // Original code
  class Foo extends Bar {
    foo() { return async () => super.bar() }
  }
  
  // Old output (with --target=es6)
  class Foo extends Bar {
    foo() {
      return () => __async(this, null, function* () {
        return super.bar();
      });
    }
  }
  
  // New output (with --target=es6)
  class Foo extends Bar {
    foo() {
      return () => {
        var __superGet = (key) => super[key];
        return __async(this, null, function* () {
          return __superGet("bar").call(this);
        });
      };
    }
  }

• Avoid merging certain CSS rules with different units (#​1732)

  This release no longer collapses border-radius, margin, padding, and inset rules when they have units with different levels of browser support. Collapsing multiple of these rules into a single rule is not equivalent if the browser supports one unit but not the other unit, since one rule would still have applied before the collapse but no longer applies after the collapse due to the whole rule being ignored. For example, Chrome 10 supports the rem unit but not the vw unit, so the CSS code below should render with rounded corners in Chrome 10. However, esbuild previously merged everything into a single rule which would cause Chrome 10 to ignore the rule and not round the corners. This issue is now fixed:

  /* Original CSS */
  div {
    border-radius: 1rem;
    border-top-left-radius: 1vw;
    margin: 0;
    margin-top: 1Q;
    left: 10Q;
    top: 20Q;
    right: 10Q;
    bottom: 20Q;
  }
  
  /* Old output (with --minify) */
  div{border-radius:1vw 1rem 1rem;margin:1Q 0 0;inset:20Q 10Q}
  
  /* New output (with --minify) */
  div{border-radius:1rem;border-top-left-radius:1vw;margin:0;margin-top:1Q;inset:20Q 10Q}

  Notice how esbuild can still collapse rules together when they all share the same unit, even if the unit is one that doesn't have universal browser support such as the unit Q. One subtlety is that esbuild now distinguishes between "safe" and "unsafe" units where safe units are old enough that they are guaranteed to work in any browser a user might reasonably use, such as px. Safe units are allowed to be collapsed together even if there are multiple different units while multiple different unsafe units are not allowed to be collapsed together. Another detail is that esbuild no longer minifies zero lengths by removing the unit if the unit is unsafe (e.g. 0rem into 0) since that could cause a rendering difference if a previously-ignored rule is now no longer ignored due to the unit change. If you are curious, you can learn more about browser support levels for different CSS units in Mozilla's documentation about CSS length units.

• Avoid warning about ignored side-effect free imports for empty files (#​1785)

  When bundling, esbuild warns about bare imports such as import "lodash-es" when the package has been marked as "sideEffects": false in its package.json file. This is because the only reason to use a bare import is because you are relying on the side effects of the import, but imports for packages marked as side-effect free are supposed to be removed. If the package indicates that it has no side effects, then this bare import is likely a bug.

  However, some people have packages just for TypeScript type definitions. These package can actually have a side effect as they can augment the type of the global object in TypeScript, even if they are marked with "sideEffects": false. To avoid warning in this case, esbuild will now only issue this warning if the imported file is non-empty. If the file is empty, then it's irrelevant whether you import it or not so any import of that file does not indicate a bug. This fixes this case because .d.ts files typically end up being empty after esbuild parses them since they typically only contain type declarations.

• Attempt to fix packages broken due to the node: prefix (#​1760)

  Some people have started using the node-specific node: path prefix in their packages. This prefix forces the following path to be interpreted as a node built-in module instead of a package on the file system. So require("node:path") will always import node's path module and never import npm's path package.

  Adding the node: prefix breaks that code with older node versions that don't understand the node: prefix. This is a problem with the package, not with esbuild. The package should be adding a fallback if the node: prefix isn't available. However, people still want to be able to use these packages with older node versions even though the code is broken. Now esbuild will automatically strip this prefix if it detects that the code will break in the configured target environment (as specified by --target=). Note that this only happens during bundling, since import paths are only examined during bundling.

eslint/eslint

v8.3.0

Compare Source

Features

• 60b0a29 feat: add allowProperties option to require-atomic-updates (#​15238) (Milos Djermanovic)
• 79278a1 feat: update no-use-before-define for class static blocks (#​15312) (Milos Djermanovic)
• ddd01dc feat: update no-redeclare for class static blocks (#​15313) (Milos Djermanovic)
• de69cec feat: update no-inner-declarations for class static blocks (#​15290) (Milos Djermanovic)
• e2fe7ef feat: support for private-in syntax (fixes #​14811) (#​15060) (Yosuke Ota)
• 34bc8d7 feat: Update espree and eslint-scope (#​15338) (Brandon Mills)
• b171cd7 feat: update max-depth for class static blocks (#​15316) (Milos Djermanovic)
• 6487df3 feat: update padded-blocks for class static blocks (#​15333) (Milos Djermanovic)
• 194f36d feat: update the complexity rule for class static blocks (#​15328) (Milos Djermanovic)
• 3530337 feat: update the indent rule for class static blocks (#​15324) (Milos Djermanovic)
• f03cd14 feat: update lines-around-comment for class static blocks (#​15323) (Milos Djermanovic)
• 5c64747 feat: update brace-style for class static blocks (#​15322) (Milos Djermanovic)
• df2f1cc feat: update max-statements for class static blocks (#​15315) (Milos Djermanovic)
• fd5a0b8 feat: update prefer-const for class static blocks (#​15325) (Milos Djermanovic)
• b3669fd feat: code path analysis for class static blocks (#​15282) (Milos Djermanovic)
• 15c1397 feat: update eslint-scope for class static blocks (#​15321) (Milos Djermanovic)
• 1a1bb4b feat: update one-var for class static blocks (#​15317) (Milos Djermanovic)
• 9b666e0 feat: update padding-line-between-statements for class static blocks (#​15318) (Milos Djermanovic)
• d3a267f feat: update class-methods-use-this for class static blocks (#​15298) (Milos Djermanovic)
• cdaa541 feat: update no-lone-blocks for class static blocks (#​15295) (Milos Djermanovic)
• 8611538 feat: update block-spacing for class static blocks (#​15297) (Milos Djermanovic)
• 7b56844 feat: update keyword-spacing for class static blocks (#​15289) (Milos Djermanovic)
• ea18711 feat: update no-extra-semi for class static blocks (#​15287) (Milos Djermanovic)
• 0f0971f feat: update semi rule for class static blocks (#​15286) (Milos Djermanovic)
• abe740c feat: add examples for block-scoped-var with class static blocks (#​15302) (Milos Djermanovic)
• 0338fd2 feat: Normalize ecmaVersion to eslint-scope when using custom parser (#​15268) (Yosuke Ota)

Bug Fixes

• 8aa7645 fix: update vars-on-top for class static blocks (#​15306) (Milos Djermanovic)
• 479a4cb fix: update semi-style for class static blocks (#​15309) (Milos Djermanovic)
• 6d1c666 fix: update no-invalid-this and no-eval for class static blocks (#​15300) (Milos Djermanovic)

Documentation

• 6b85426 docs: Expand --debug option description in the CLI documentation (#​15308) (darkred)
• 3ae5258 docs: the strict rule does not apply to class static blocks (#​15314) (Milos Djermanovic)
• 9309841 docs: Remove inconsistent colon in pull request docs (#​15303) (Jordan Eldredge)
• da238cc docs: remove deprecation note from lines-around-comment (#​15293) (Milos Djermanovic)
• 1055f16 docs: no-unused-expressions - class static blocks don't have directives (#​15283) (Milos Djermanovic)
• 4c55216 docs: Add variables option to no-use-before-define (#​15276) (Mathias Rasmussen)

Chores

• edd8d24 chore: upgrade eslint-visitor-keys for class static blocks (#​15277) (Milos Djermanovic)

webpack/webpack

v5.64.2

Compare Source

Bugfixes

• avoid double initial compilation due to invalid dependencies with managedPaths

---

Configuration

📅 Schedule: "after 10pm every weekday,before 4am every weekday,every weekend" in timezone America/Tijuana.

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

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

👻 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.

[angular-automatic-lock-bot]

This issue has been automatically locked due to inactivity.
Please file a new issue if you are encountering a similar or related problem.

Read more about our automatic conversation locking policy.

_{This action has been performed automatically by a bot.}