chore(deps): update dependency esbuild to v0.14.9 #1258

renovate · 2021-12-29T01:02:55Z

renovate commented

2021-12-29 01:02:55 +00:00

This PR contains the following updates:

Package	Type	Update	Change
esbuild	devDependencies	patch	`0.14.8` -> `0.14.9`

Release Notes

evanw/esbuild

`v0.14.9`

Compare Source

Implement cross-module tree shaking of TypeScript enum values (#128)

If your bundle uses TypeScript enums across multiple files, esbuild is able to inline the enum values as long as you export and import the enum using the ES module export and import keywords. However, this previously still left the definition of the enum in the bundle even when it wasn't used anymore. This was because esbuild's tree shaking (i.e. dead code elimination) is based on information recorded during parsing, and at that point we don't know which imported symbols are inlined enum values and which aren't.

With this release, esbuild will now remove enum definitions that become unused due to cross-module enum value inlining. Property accesses off of imported symbols are now tracked separately during parsing and then resolved during linking once all inlined enum values are known. This behavior change means esbuild's support for cross-module inlining of TypeScript enums is now finally complete. Here's an example:
```
// entry.ts
import { Foo } from './enum'
console.log(Foo.Bar)

// enum.ts
export enum Foo { Bar }
```
Bundling the example code above now results in the enum definition being completely removed from the bundle:
```
// Old output (with --bundle --minify --format=esm)
var r=(o=>(o[o.Bar=0]="Bar",o))(r||{});console.log(0);

// New output (with --bundle --minify --format=esm)
console.log(0);
```
Fix a regression with export {} from and CommonJS (#1890)

This release fixes a regression that was introduced by the change in 0.14.7 that avoids calling the __toESM wrapper for import statements that are converted to require calls and that don't use the default or __esModule export names. The previous change was correct for the import {} from syntax but not for the export {} from syntax, which meant that in certain cases with re-exported values, the value of the default import could be different than expected. This release fixes the regression.

Warn about using module or exports in ESM code (#1887)

CommonJS export variables cannot be referenced in ESM code. If you do this, they are treated as global variables instead. This release includes a warning for people that try to use both CommonJS and ES module export styles in the same file. Here's an example:

export enum Something {
  a,
  b,
}
module.exports = { a: 1, b: 2 }

Running esbuild on that code now generates a warning that looks like this:

▲ [WARNING] The CommonJS "module" variable is treated as a global variable in an ECMAScript module and may not work as expected

    example.ts:5:0:
      5 │ module.exports = { a: 1, b: 2 }
        ╵ ~~~~~~

  This file is considered to be an ECMAScript module because of the "export" keyword here:

    example.ts:1:0:
      1 │ export enum Something {
        ╵ ~~~~~~

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, check this box.

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.8` -> `0.14.9`](https://renovatebot.com/diffs/npm/esbuild/0.14.8/0.14.9) | --- ### Release Notes <details> <summary>evanw/esbuild</summary> ### [`v0.14.9`](https://github.com/evanw/esbuild/blob/master/CHANGELOG.md#0149) [Compare Source](https://github.com/evanw/esbuild/compare/v0.14.8...v0.14.9) - Implement cross-module tree shaking of TypeScript enum values ([#128](https://github.com/evanw/esbuild/issues/128)) If your bundle uses TypeScript enums across multiple files, esbuild is able to inline the enum values as long as you export and import the enum using the ES module `export` and `import` keywords. However, this previously still left the definition of the enum in the bundle even when it wasn't used anymore. This was because esbuild's tree shaking (i.e. dead code elimination) is based on information recorded during parsing, and at that point we don't know which imported symbols are inlined enum values and which aren't. With this release, esbuild will now remove enum definitions that become unused due to cross-module enum value inlining. Property accesses off of imported symbols are now tracked separately during parsing and then resolved during linking once all inlined enum values are known. This behavior change means esbuild's support for cross-module inlining of TypeScript enums is now finally complete. Here's an example: ```js // entry.ts import { Foo } from './enum' console.log(Foo.Bar) // enum.ts export enum Foo { Bar } ``` Bundling the example code above now results in the enum definition being completely removed from the bundle: ```js // Old output (with --bundle --minify --format=esm) var r=(o=>(o[o.Bar=0]="Bar",o))(r||{});console.log(0); // New output (with --bundle --minify --format=esm) console.log(0); ``` - Fix a regression with `export {} from` and CommonJS ([#1890](https://github.com/evanw/esbuild/issues/1890)) This release fixes a regression that was introduced by the change in 0.14.7 that avoids calling the `__toESM` wrapper for import statements that are converted to `require` calls and that don't use the `default` or `__esModule` export names. The previous change was correct for the `import {} from` syntax but not for the `export {} from` syntax, which meant that in certain cases with re-exported values, the value of the `default` import could be different than expected. This release fixes the regression. - Warn about using `module` or `exports` in ESM code ([#1887](https://github.com/evanw/esbuild/issues/1887)) CommonJS export variables cannot be referenced in ESM code. If you do this, they are treated as global variables instead. This release includes a warning for people that try to use both CommonJS and ES module export styles in the same file. Here's an example: ```ts export enum Something { a, b, } module.exports = { a: 1, b: 2 } ``` Running esbuild on that code now generates a warning that looks like this: ▲ [WARNING] The CommonJS "module" variable is treated as a global variable in an ECMAScript module and may not work as expected example.ts:5:0: 5 │ module.exports = { a: 1, b: 2 } ╵ ~~~~~~ This file is considered to be an ECMAScript module because of the "export" keyword here: example.ts:1:0: 1 │ export enum Something { ╵ ~~~~~~ </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. --- - [ ] If you want to rebase/retry this PR, check this box. --- This PR has been generated by [Renovate Bot](https://github.com/renovatebot/renovate).

renovate added the

dependencies

label 2021-12-29 01:02:55 +00:00

renovate added 1 commit 2021-12-29 01:02:56 +00:00

continuous-integration/drone/pr Build is passing Details

32887487ec chore(deps): update dependency esbuild to v0.14.9

frederick commented

2021-12-29 01:07:12 +00:00

Hi renovate!

Thank you for creating a PR!

I've deployed the changes of this PR on a preview environment under this URL: https://1258-renovateesbuild-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://1258-renovateesbuild-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 8c62c96109 into main

2021-12-29 13:34:16 +00:00

konrad deleted branch renovate/esbuild-0.x

2021-12-29 13:34:17 +00:00

konrad referenced this issue from a commit

2021-12-29 13:34:17 +00:00

chore(deps): update dependency esbuild to v0.14.9 (#1258)

This repo is archived. You cannot comment on pull requests.

No reviewers