chore(deps): update dependency esbuild to v0.15.4 #2270

Merged
konrad merged 1 commits from renovate/esbuild-0.x into main 2022-08-16 19:35:41 +00:00
Member

This PR contains the following updates:

Package Type Update Change
esbuild devDependencies patch 0.15.3 -> 0.15.4

Release Notes

evanw/esbuild

v0.15.4

Compare Source

  • Consider TypeScript import assignments to be side-effect free (#​2468)

    TypeScript has a legacy import syntax for working with TypeScript namespaces that looks like this:

    import { someNamespace } from './some-file'
    import bar = someNamespace.foo;
    
    // some-file.ts
    export namespace someNamespace {
      export let foo = 123
    }
    

    Since esbuild converts TypeScript into JavaScript one file at a time, it doesn't know if bar is supposed to be a value or a type (or both, which TypeScript actually allows in this case). This is problematic because values are supposed to be kept during the conversion but types are supposed to be removed during the conversion. Currently esbuild keeps bar in the output, which is done because someNamespace.foo is a property access and property accesses run code that could potentially have a side effect (although there is no side effect in this case).

    With this release, esbuild will now consider someNamespace.foo to have no side effects. This means bar will now be removed when bundling and when tree shaking is enabled. Note that it will still not be removed when tree shaking is disabled. This is because in this mode, esbuild supports adding additional code to the end of the generated output that's in the same scope as the module. That code could potentially make use of bar, so it would be incorrect to remove it. If you want bar to be removed, you'll have to enable tree shaking (which tells esbuild that nothing else depends on the unexported top-level symbols in the generated output).

  • Change the order of the banner and the "use strict" directive (#​2467)

    Previously the top of the file contained the following things in order:

    1. The hashbang comment (see below) from the source code, if present
    2. The "use strict" directive from the source code, if present
    3. The content of esbuild's banner API option, if specified

    This was problematic for people that used the banner API option to insert the hashbang comment instead of using esbuild's hashbang comment preservation feature. So with this release, the order has now been changed to:

    1. The hashbang comment (see below) from the source code, if present
    2. The content of esbuild's banner API option, if specified
    3. The "use strict" directive from the source code, if present

    I'm considering this change to be a bug fix instead of a breaking change because esbuild's documentation states that the banner API option can be used to "insert an arbitrary string at the beginning of generated JavaScript files". While this isn't technically true because esbuild may still insert the original hashbang comment before the banner, it's at least more correct now because the banner will now come before the "use strict" directive.

    For context: JavaScript files recently allowed using a hashbang comment, which starts with #! and which must start at the very first character of the file. It allows Unix systems to execute the file directly as a script without needing to prefix it by the node command. This comment typically has the value #!/usr/bin/env node. Hashbang comments will be a part of ES2023 when it's released next year.

  • Fix exports maps with Yarn PnP path resolution (#​2473)

    The Yarn PnP specification says that to resolve a package path, you first resolve it to the absolute path of a directory, and then you run node's module resolution algorithm on it. Previously esbuild followed this part of the specification. However, doing this means that exports in package.json is not respected because node's module resolution algorithm doesn't interpret exports for absolute paths. So with this release, esbuild will now use a modified algorithm that deviates from both specifications but that should hopefully behave more similar to what Yarn actually does: node's module resolution algorithm is run with the original import path but starting from the directory returned by Yarn PnP.


Configuration

📅 Schedule: Branch creation - At any time (no schedule defined), Automerge - 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.15.3` -> `0.15.4`](https://renovatebot.com/diffs/npm/esbuild/0.15.3/0.15.4) | --- ### Release Notes <details> <summary>evanw/esbuild</summary> ### [`v0.15.4`](https://github.com/evanw/esbuild/blob/HEAD/CHANGELOG.md#&#8203;0154) [Compare Source](https://github.com/evanw/esbuild/compare/v0.15.3...v0.15.4) - Consider TypeScript import assignments to be side-effect free ([#&#8203;2468](https://github.com/evanw/esbuild/issues/2468)) TypeScript has a [legacy import syntax](https://www.typescriptlang.org/docs/handbook/namespaces.html#aliases) for working with TypeScript namespaces that looks like this: ```ts import { someNamespace } from './some-file' import bar = someNamespace.foo; // some-file.ts export namespace someNamespace { export let foo = 123 } ``` Since esbuild converts TypeScript into JavaScript one file at a time, it doesn't know if `bar` is supposed to be a value or a type (or both, which TypeScript actually allows in this case). This is problematic because values are supposed to be kept during the conversion but types are supposed to be removed during the conversion. Currently esbuild keeps `bar` in the output, which is done because `someNamespace.foo` is a property access and property accesses run code that could potentially have a side effect (although there is no side effect in this case). With this release, esbuild will now consider `someNamespace.foo` to have no side effects. This means `bar` will now be removed when bundling and when tree shaking is enabled. Note that it will still not be removed when tree shaking is disabled. This is because in this mode, esbuild supports adding additional code to the end of the generated output that's in the same scope as the module. That code could potentially make use of `bar`, so it would be incorrect to remove it. If you want `bar` to be removed, you'll have to enable tree shaking (which tells esbuild that nothing else depends on the unexported top-level symbols in the generated output). - Change the order of the banner and the `"use strict"` directive ([#&#8203;2467](https://github.com/evanw/esbuild/issues/2467)) Previously the top of the file contained the following things in order: 1. The hashbang comment (see below) from the source code, if present 2. The `"use strict"` directive from the source code, if present 3. The content of esbuild's `banner` API option, if specified This was problematic for people that used the `banner` API option to insert the hashbang comment instead of using esbuild's hashbang comment preservation feature. So with this release, the order has now been changed to: 1. The hashbang comment (see below) from the source code, if present 2. The content of esbuild's `banner` API option, if specified 3. The `"use strict"` directive from the source code, if present I'm considering this change to be a bug fix instead of a breaking change because esbuild's documentation states that the `banner` API option can be used to "insert an arbitrary string at the beginning of generated JavaScript files". While this isn't technically true because esbuild may still insert the original hashbang comment before the banner, it's at least more correct now because the banner will now come before the `"use strict"` directive. For context: JavaScript files recently allowed using a [hashbang comment](https://github.com/tc39/proposal-hashbang), which starts with `#!` and which must start at the very first character of the file. It allows Unix systems to execute the file directly as a script without needing to prefix it by the `node` command. This comment typically has the value `#!/usr/bin/env node`. Hashbang comments will be a part of ES2023 when it's released next year. - Fix `exports` maps with Yarn PnP path resolution ([#&#8203;2473](https://github.com/evanw/esbuild/issues/2473)) The Yarn PnP specification says that to resolve a package path, you first resolve it to the absolute path of a directory, and then you run node's module resolution algorithm on it. Previously esbuild followed this part of the specification. However, doing this means that `exports` in `package.json` is not respected because node's module resolution algorithm doesn't interpret `exports` for absolute paths. So with this release, esbuild will now use a modified algorithm that deviates from both specifications but that should hopefully behave more similar to what Yarn actually does: node's module resolution algorithm is run with the original import path but starting from the directory returned by Yarn PnP. </details> --- ### Configuration 📅 **Schedule**: Branch creation - At any time (no schedule defined), Automerge - 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-debug:eyJjcmVhdGVkSW5WZXIiOiIzMi4xNTMuNCIsInVwZGF0ZWRJblZlciI6IjMyLjE1My40In0=-->
renovate added the
dependencies
label 2022-08-16 19:02:53 +00:00
renovate added 1 commit 2022-08-16 19:02:53 +00:00
continuous-integration/drone/pr Build is passing Details
b38223fabe
chore(deps): update dependency esbuild to v0.15.4
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://2270-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://2270-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 01c29578fb into main 2022-08-16 19:35:41 +00:00
konrad deleted branch renovate/esbuild-0.x 2022-08-16 19:35:41 +00:00
This repo is archived. You cannot comment on pull requests.
No description provided.