chore(deps): update dependency esbuild to v0.14.38

[renovate]

This PR contains the following updates:

Package	Change	Age	Adoption	Passing	Confidence
esbuild	0.14.36 -> 0.14.38

---

Release Notes

evanw/esbuild

v0.14.38

Compare Source

• Further fixes to TypeScript 4.7 instantiation expression parsing (#​2201)

  This release fixes some additional edge cases with parsing instantiation expressions from the upcoming version 4.7 of TypeScript. Previously it was allowed for an instantiation expression to precede a binary operator but with this release, that's no longer allowed. This was sometimes valid in the TypeScript 4.7 beta but is no longer allowed in the latest version of TypeScript 4.7. Fixing this also fixed a regression that was introduced by the previous release of esbuild:

  Code	TS 4.6.3	TS 4.7.0 beta	TS 4.7.0 nightly	esbuild 0.14.36	esbuild 0.14.37	esbuild 0.14.38
  a<b> == c<d>	Invalid	a == c	Invalid	a == c	a == c	Invalid
  a<b> in c<d>	Invalid	Invalid	Invalid	Invalid	a in c	Invalid
  a<b>>=c<d>	Invalid	Invalid	Invalid	Invalid	a >= c	Invalid
  a<b>=c<d>	Invalid	a < b >= c	a = c	a < b >= c	a = c	a = c
  a<b>>c<d>	a < b >> c	a < b >> c	a < b >> c	a < b >> c	a > c	a < b >> c

  This table illustrates some of the more significant changes between all of these parsers. The most important part is that esbuild 0.14.38 now matches the behavior of the latest TypeScript compiler for all of these cases.

v0.14.37

Compare Source

• Add support for TypeScript's moduleSuffixes field from TypeScript 4.7

  The upcoming version of TypeScript adds the moduleSuffixes field to tsconfig.json that introduces more rules to import path resolution. Setting moduleSuffixes to [".ios", ".native", ""] will try to look at the the relative files ./foo.ios.ts, ./foo.native.ts, and finally ./foo.ts for an import path of ./foo. Note that the empty string "" in moduleSuffixes is necessary for TypeScript to also look-up ./foo.ts. This was announced in the TypeScript 4.7 beta blog post.

• Match the new ASI behavior from TypeScript nightly builds (#​2188)

  This release updates esbuild to match some very recent behavior changes in the TypeScript parser regarding automatic semicolon insertion. For more information, see TypeScript issues #​48711 and #​48654 (I'm not linking to them directly to avoid Dependabot linkback spam on these issues due to esbuild's popularity). The result is that the following TypeScript code is now considered valid TypeScript syntax:

  class A<T> {}
  new A<number> /* ASI now happens here */
  if (0) {}
  
  interface B {
    (a: number): typeof a /* ASI now happens here */
    <T>(): void
  }

  This fix was contributed by @​g-plane.

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.

---

Configuration

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

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

♻ 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]

⚠ Artifact update problem

Renovate failed to update an artifact related to this branch. You probably do not want to merge this PR as-is.

♻ Renovate will retry this branch, including artifacts, only when one of the following happens:

• any of the package files in this branch needs updating, or
• the branch becomes conflicted, or
• you click the rebase/retry checkbox if found above, or
• you rename this PR's title to start with "rebase!" to trigger it manually

The artifact failure details are included below:

File name: package-lock.json

npm notice 
npm notice New minor version of npm available! 8.5.0 -> 8.7.0
npm notice Changelog: <https://github.com/npm/cli/releases/tag/v8.7.0>
npm notice Run `npm install -g npm@8.7.0` to update!
npm notice 
npm WARN ERESOLVE overriding peer dependency
npm WARN While resolving: undefined@0.0.1
npm WARN Found: @typescript-eslint/eslint-plugin@5.18.0
npm WARN node_modules/@typescript-eslint/eslint-plugin
npm WARN   dev @typescript-eslint/eslint-plugin@"5.19.0" from the root project
npm WARN   1 more (eslint-plugin-unused-imports)
npm WARN 
npm WARN Could not resolve dependency:
npm WARN peer @typescript-eslint/eslint-plugin@"^4.0.1" from eslint-config-standard-with-typescript@21.0.1
npm WARN node_modules/eslint-config-standard-with-typescript
npm WARN   dev eslint-config-standard-with-typescript@"21.0.1" from the root project
npm ERR! code ERESOLVE
npm ERR! ERESOLVE could not resolve
npm ERR! 
npm ERR! While resolving: eslint-config-standard@16.0.3
npm ERR! Found: eslint@8.13.0
npm ERR! node_modules/eslint
npm ERR!   dev eslint@"8.13.0" from the root project
npm ERR!   peer eslint@"^6.0.0 || ^7.0.0 || ^8.0.0" from @typescript-eslint/experimental-utils@5.16.0
npm ERR!   node_modules/@typescript-eslint/experimental-utils
npm ERR!     @typescript-eslint/experimental-utils@"^5.0.0" from eslint-plugin-typescript-sort-keys@2.1.0
npm ERR!     node_modules/eslint-plugin-typescript-sort-keys
npm ERR!       dev eslint-plugin-typescript-sort-keys@"2.1.0" from the root project
npm ERR!   20 more (@typescript-eslint/utils, eslint-config-prettier, ...)
npm ERR! 
npm ERR! Could not resolve dependency:
npm ERR! peer eslint@"^7.12.1" from eslint-config-standard@16.0.3
npm ERR! node_modules/eslint-config-standard
npm ERR!   dev eslint-config-standard@"16.0.3" from the root project
npm ERR!   eslint-config-standard@"^16.0.0" from eslint-config-standard-with-typescript@21.0.1
npm ERR!   node_modules/eslint-config-standard-with-typescript
npm ERR!     dev eslint-config-standard-with-typescript@"21.0.1" from the root project
npm ERR! 
npm ERR! Conflicting peer dependency: eslint@7.32.0
npm ERR! node_modules/eslint
npm ERR!   peer eslint@"^7.12.1" from eslint-config-standard@16.0.3
npm ERR!   node_modules/eslint-config-standard
npm ERR!     dev eslint-config-standard@"16.0.3" from the root project
npm ERR!     eslint-config-standard@"^16.0.0" from eslint-config-standard-with-typescript@21.0.1
npm ERR!     node_modules/eslint-config-standard-with-typescript
npm ERR!       dev eslint-config-standard-with-typescript@"21.0.1" from the root project
npm ERR! 
npm ERR! Fix the upstream dependency conflict, or retry
npm ERR! this command with --force, or --legacy-peer-deps
npm ERR! to accept an incorrect (and potentially broken) dependency resolution.
npm ERR! 
npm ERR! See /tmp/renovate-cache/others/npm/eresolve-report.txt for a full report.

npm ERR! A complete log of this run can be found in:
npm ERR!     /tmp/renovate-cache/others/npm/_logs/2022-04-21T22_41_31_260Z-debug-0.log