chore(deps): update dependency esbuild to v0.16.2 #2802

Merged
konrad merged 1 commits from renovate/esbuild-0.x into main 2022-12-08 09:32:29 +00:00
Member

This PR contains the following updates:

Package Type Update Change
esbuild devDependencies patch 0.16.1 -> 0.16.2

Release Notes

evanw/esbuild

v0.16.2

Compare Source

  • Fix process.env.NODE_ENV substitution when transforming (#​2718)

    Version 0.16.0 introduced an unintentional regression that caused process.env.NODE_ENV to be automatically substituted with either "development" or "production" when using esbuild's transform API. This substitution is a necessary feature of esbuild's build API because the React framework crashes when you bundle it without doing this. But the transform API is typically used as part of a larger build pipeline so the benefit of esbuild doing this automatically is not as clear, and esbuild previously didn't do this.

    However, version 0.16.0 switched the default value of the platform setting for the transform API from neutral to browser, both to align it with esbuild's documentation (which says browser is the default value) and because escaping the </script> character sequence is now tied to the browser platform (see the release notes for version 0.16.0 for details). That accidentally enabled automatic substitution of process.env.NODE_ENV because esbuild always did that for code meant for the browser. To fix this regression, esbuild will now only automatically substitute process.env.NODE_ENV when using the build API.

  • Prevent define from substituting constants into assignment position (#​2719)

    The define feature lets you replace certain expressions with constants. For example, you could use it to replace references to the global property reference window.DEBUG with false at compile time, which can then potentially help esbuild remove unused code from your bundle. It's similar to DefinePlugin in Webpack.

    However, if you write code such as window.DEBUG = true and then defined window.DEBUG to false, esbuild previously generated the output false = true which is a syntax error in JavaScript. This behavior is not typically a problem because it doesn't make sense to substitute window.DEBUG with a constant if its value changes at run-time (Webpack's DefinePlugin also generates false = true in this case). But it can be alarming to have esbuild generate code with a syntax error.

    So with this release, esbuild will no longer substitute define constants into assignment position to avoid generating code with a syntax error. Instead esbuild will generate a warning, which currently looks like this:

    ▲ [WARNING] Suspicious assignment to defined constant "window.DEBUG" [assign-to-define]
    
        example.js:1:0:
          1 │ window.DEBUG = true
            ╵ ~~~~~~~~~~~~
    
      The expression "window.DEBUG" has been configured to be replaced with a constant using the
      "define" feature. If this expression is supposed to be a compile-time constant, then it doesn't
      make sense to assign to it here. Or if this expression is supposed to change at run-time, this
      "define" substitution should be removed.
    
  • Fix a regression with npm install --no-optional (#​2720)

    Normally when you install esbuild with npm install, npm itself is the tool that downloads the correct binary executable for the current platform. This happens because of how esbuild's primary package uses npm's optionalDependencies feature. However, if you deliberately disable this with npm install --no-optional then esbuild's install script will attempt to repair the installation by manually downloading and extracting the binary executable from the package that was supposed to be installed.

    The change in version 0.16.0 to move esbuild's nested packages into the @esbuild/ scope unintentionally broke this logic because of how npm's URL structure is different for scoped packages vs. normal packages. It was actually already broken for a few platforms earlier because esbuild already had packages for some platforms in the @esbuild/ scope, but I didn't discover this then because esbuild's integration tests aren't run on all platforms. Anyway, this release contains some changes to the install script that should hopefully get this scenario working again.


Configuration

📅 Schedule: Branch creation - At any time (no schedule defined), Automerge - 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 Renovate Bot.

This PR contains the following updates: | Package | Type | Update | Change | |---|---|---|---| | [esbuild](https://github.com/evanw/esbuild) | devDependencies | patch | [`0.16.1` -> `0.16.2`](https://renovatebot.com/diffs/npm/esbuild/0.16.1/0.16.2) | --- ### Release Notes <details> <summary>evanw/esbuild</summary> ### [`v0.16.2`](https://github.com/evanw/esbuild/blob/HEAD/CHANGELOG.md#&#8203;0162) [Compare Source](https://github.com/evanw/esbuild/compare/v0.16.1...v0.16.2) - Fix `process.env.NODE_ENV` substitution when transforming ([#&#8203;2718](https://github.com/evanw/esbuild/issues/2718)) Version 0.16.0 introduced an unintentional regression that caused `process.env.NODE_ENV` to be automatically substituted with either `"development"` or `"production"` when using esbuild's `transform` API. This substitution is a necessary feature of esbuild's `build` API because the React framework crashes when you bundle it without doing this. But the `transform` API is typically used as part of a larger build pipeline so the benefit of esbuild doing this automatically is not as clear, and esbuild previously didn't do this. However, version 0.16.0 switched the default value of the `platform` setting for the `transform` API from `neutral` to `browser`, both to align it with esbuild's documentation (which says `browser` is the default value) and because escaping the `</script>` character sequence is now tied to the `browser` platform (see the release notes for version 0.16.0 for details). That accidentally enabled automatic substitution of `process.env.NODE_ENV` because esbuild always did that for code meant for the browser. To fix this regression, esbuild will now only automatically substitute `process.env.NODE_ENV` when using the `build` API. - Prevent `define` from substituting constants into assignment position ([#&#8203;2719](https://github.com/evanw/esbuild/issues/2719)) The `define` feature lets you replace certain expressions with constants. For example, you could use it to replace references to the global property reference `window.DEBUG` with `false` at compile time, which can then potentially help esbuild remove unused code from your bundle. It's similar to [DefinePlugin](https://webpack.js.org/plugins/define-plugin/) in Webpack. However, if you write code such as `window.DEBUG = true` and then defined `window.DEBUG` to `false`, esbuild previously generated the output `false = true` which is a syntax error in JavaScript. This behavior is not typically a problem because it doesn't make sense to substitute `window.DEBUG` with a constant if its value changes at run-time (Webpack's `DefinePlugin` also generates `false = true` in this case). But it can be alarming to have esbuild generate code with a syntax error. So with this release, esbuild will no longer substitute `define` constants into assignment position to avoid generating code with a syntax error. Instead esbuild will generate a warning, which currently looks like this: ▲ [WARNING] Suspicious assignment to defined constant "window.DEBUG" [assign-to-define] example.js:1:0: 1 │ window.DEBUG = true ╵ ~~~~~~~~~~~~ The expression "window.DEBUG" has been configured to be replaced with a constant using the "define" feature. If this expression is supposed to be a compile-time constant, then it doesn't make sense to assign to it here. Or if this expression is supposed to change at run-time, this "define" substitution should be removed. - Fix a regression with `npm install --no-optional` ([#&#8203;2720](https://github.com/evanw/esbuild/issues/2720)) Normally when you install esbuild with `npm install`, npm itself is the tool that downloads the correct binary executable for the current platform. This happens because of how esbuild's primary package uses npm's `optionalDependencies` feature. However, if you deliberately disable this with `npm install --no-optional` then esbuild's install script will attempt to repair the installation by manually downloading and extracting the binary executable from the package that was supposed to be installed. The change in version 0.16.0 to move esbuild's nested packages into the `@esbuild/` scope unintentionally broke this logic because of how npm's URL structure is different for scoped packages vs. normal packages. It was actually already broken for a few platforms earlier because esbuild already had packages for some platforms in the `@esbuild/` scope, but I didn't discover this then because esbuild's integration tests aren't run on all platforms. Anyway, this release contains some changes to the install script that should hopefully get this scenario working again. </details> --- ### Configuration 📅 **Schedule**: Branch creation - At any time (no schedule defined), Automerge - 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. --- - [ ] <!-- 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-debug:eyJjcmVhdGVkSW5WZXIiOiIzMi4yNDAuMiIsInVwZGF0ZWRJblZlciI6IjMyLjI0MC4yIn0=-->
renovate added the
dependencies
label 2022-12-08 07:03:52 +00:00
renovate added 1 commit 2022-12-08 07:03:52 +00:00
continuous-integration/drone/pr Build is passing Details
a4169da4fc
chore(deps): update dependency esbuild to v0.16.2
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://2802-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://2802-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.
konrad merged commit b97e045118 into main 2022-12-08 09:32:29 +00:00
konrad deleted branch renovate/esbuild-0.x 2022-12-08 09:32:29 +00:00
This repo is archived. You cannot comment on pull requests.
No description provided.