chore(deps): update dependency esbuild to v0.14.36 #1815

Merged
dpschen merged 1 commits from renovate/esbuild-0.x into main 2022-04-13 16:53:14 +00:00
Member

This PR contains the following updates:

Package Type Update Change
esbuild devDependencies patch 0.14.34 -> 0.14.36

Release Notes

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.


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 Renovate Bot.

This PR contains the following updates: | Package | Type | Update | Change | |---|---|---|---| | [esbuild](https://github.com/evanw/esbuild) | devDependencies | patch | [`0.14.34` -> `0.14.36`](https://renovatebot.com/diffs/npm/esbuild/0.14.34/0.14.36) | --- ### Release Notes <details> <summary>evanw/esbuild</summary> ### [`v0.14.36`](https://github.com/evanw/esbuild/blob/master/CHANGELOG.md#&#8203;01436) [Compare Source](https://github.com/evanw/esbuild/compare/v0.14.35...v0.14.36) - Revert path metadata validation for now ([#&#8203;2177](https://github.com/evanw/esbuild/issues/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`](https://github.com/evanw/esbuild/blob/master/CHANGELOG.md#&#8203;01435) [Compare Source](https://github.com/evanw/esbuild/compare/v0.14.34...v0.14.35) - Add support for parsing `typeof` on #private fields from TypeScript 4.7 ([#&#8203;2174](https://github.com/evanw/esbuild/pull/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 ```ts 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 [@&#8203;magic-akari](https://github.com/magic-akari). - Add Opera and IE to internal CSS feature support matrix ([#&#8203;2170](https://github.com/evanw/esbuild/pull/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: ```css /* 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:#&#8203;00000080} ``` The fix for this issue was contributed by [@&#8203;sapphi-red](https://github.com/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: ```js 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 ([#&#8203;2163](https://github.com/evanw/esbuild/issues/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 "@&#8203;sentry/electron/main" index.js:1:24: 1 │ import * as Sentry from '@&#8203;sentry/electron/main' ╵ ~~~~~~~~~~~~~~~~~~~~~~~ The path "./main" is not currently exported by package "@&#8203;sentry/electron": node_modules/@&#8203;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/@&#8203;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/@&#8203;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 '@&#8203;sentry/electron/main' ╵ ~~~~~~~~~~~~~~~~~~~~~~~ You can mark the path "@&#8203;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. </details> --- ### 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. --- - [ ] <!-- rebase-check -->If you want to rebase/retry this PR, click this checkbox. --- This PR has been generated by [Renovate Bot](https://github.com/renovatebot/renovate).
renovate added the
dependencies
label 2022-04-12 02:07:23 +00:00
Member

Hi renovate!

Thank you for creating a PR!

I've deployed the changes of this PR on a preview environment under this URL: https://1815-renovate-esbuild-0-x--vikunja-frontend-preview.netlify.app

You can use this url to view the changes live and test them out.
You will need to manually connect this to an api running somehwere. The easiest to use is https://try.vikunja.io/.

Have a nice day!

Beep boop, I'm a bot.

Hi renovate! Thank you for creating a PR! I've deployed the changes of this PR on a preview environment under this URL: https://1815-renovate-esbuild-0-x--vikunja-frontend-preview.netlify.app You can use this url to view the changes live and test them out. You will need to manually connect this to an api running somehwere. The easiest to use is https://try.vikunja.io/. Have a nice day! > Beep boop, I'm a bot.
renovate changed title from chore(deps): update dependency esbuild to v0.14.35 to chore(deps): update dependency esbuild to v0.14.36 2022-04-12 07:07:13 +00:00
renovate force-pushed renovate/esbuild-0.x from cc9282ca75 to e7ea28209b 2022-04-12 07:07:15 +00:00 Compare
dpschen approved these changes 2022-04-13 16:53:07 +00:00
dpschen merged commit baad9107b9 into main 2022-04-13 16:53:14 +00:00
dpschen deleted branch renovate/esbuild-0.x 2022-04-13 16:53:14 +00:00
This repo is archived. You cannot comment on pull requests.
No description provided.