Skip to content

Update dependency esbuild to v0.14.9#3

Merged
maxmilton merged 1 commit intomasterfrom
renovate/esbuild-0.x
Dec 29, 2021
Merged

Update dependency esbuild to v0.14.9#3
maxmilton merged 1 commit intomasterfrom
renovate/esbuild-0.x

Conversation

@renovate
Copy link
Copy Markdown
Contributor

@renovate renovate bot commented Dec 29, 2021

WhiteSource Renovate

This PR contains the following updates:

Package Change Age Adoption Passing Confidence
esbuild 0.14.8 -> 0.14.9 age adoption passing confidence

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, click this checkbox.

This PR has been generated by WhiteSource Renovate. View repository job log here.

@maxmilton maxmilton merged commit 7ceb8e3 into master Dec 29, 2021
@maxmilton maxmilton deleted the renovate/esbuild-0.x branch December 29, 2021 05:50
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants