Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

build(deps-dev): bump esbuild from 0.14.0 to 0.14.1 #3117

Merged
merged 1 commit into from Dec 1, 2021

Conversation

dependabot[bot]
Copy link
Contributor

@dependabot dependabot bot commented on behalf of github Nov 30, 2021

Bumps esbuild from 0.14.0 to 0.14.1.

Release notes

Sourced from esbuild's releases.

v0.14.1

  • Fix imports in package.json (#1807)

    This release contains a fix for the rarely-used imports feature in package.json files that lets a package specify a custom remapping for import paths inside that package that start with #. Support for imports was added in version 0.13.9. However, the field was being incorrectly interpreted as relative to the importing file instead of to the package.json file, which caused an import failure when the importing file is in a subdirectory instead of being at the top level of the package. Import paths should now be interpreted as relative to the correct directory which should fix these path resolution failures.

  • Isolate implicit sibling scope lookup for enum and namespace

    The previous release implemented sibling namespaces in TypeScript, which introduces a new kind of scope lookup that doesn't exist in JavaScript. Exported members inside an enum or namespace block can be implicitly referenced in a sibling enum or namespace block just by using the name without using a property reference. However, this behavior appears to only work for enum-to-enum and namespace-to-namespace interactions. Even though sibling enums and namespaces with the same name can be merged together into the same underlying object, this implicit reference behavior doesn't work for enum-to-namespace interactions and attempting to do this with a namespace-to-enum interaction causes the TypeScript compiler itself to crash. Here is an example of how the TypeScript compiler behaves in each case:

    // "b" is accessible
    enum a { b = 1 }
    enum a { c = b }
    // "e" is accessible
    namespace d { export let e = 1 }
    namespace d { export let f = e }
    // "h" is inaccessible
    enum g { h = 1 }
    namespace g { export let i = h }
    // This causes the TypeScript compiler to crash
    namespace j { export let k = 1 }
    enum j { l = k }

    This release changes the implicit sibling scope lookup behavior to only work for enum-to-enum and namespace-to-namespace interactions. These implicit references no longer work with enum-to-namespace and namespace-to-enum interactions, which should more accurately match the behavior of the TypeScript compiler.

  • Add semicolon insertion before TypeScript-specific definite assignment assertion modifier (#1810)

    TypeScript lets you add a ! after a variable declaration to bypass TypeScript's definite assignment analysis:

    let x!: number[];
    initialize();
    x.push(4);
    function initialize() { x = [0, 1, 2, 3]; }

    This ! is called a definite assignment assertion and tells TypeScript to assume that the variable has been initialized somehow. However, JavaScript's automatic semicolon insertion rules should be able to insert a semicolon before it:

    let a
    !function(){}()

    Previously the above code was incorrectly considered a syntax error in TypeScript. With this release, this code is now parsed correctly.

... (truncated)

Changelog

Sourced from esbuild's changelog.

0.14.1

  • Fix imports in package.json (#1807)

    This release contains a fix for the rarely-used imports feature in package.json files that lets a package specify a custom remapping for import paths inside that package that start with #. Support for imports was added in version 0.13.9. However, the field was being incorrectly interpreted as relative to the importing file instead of to the package.json file, which caused an import failure when the importing file is in a subdirectory instead of being at the top level of the package. Import paths should now be interpreted as relative to the correct directory which should fix these path resolution failures.

  • Isolate implicit sibling scope lookup for enum and namespace

    The previous release implemented sibling namespaces in TypeScript, which introduces a new kind of scope lookup that doesn't exist in JavaScript. Exported members inside an enum or namespace block can be implicitly referenced in a sibling enum or namespace block just by using the name without using a property reference. However, this behavior appears to only work for enum-to-enum and namespace-to-namespace interactions. Even though sibling enums and namespaces with the same name can be merged together into the same underlying object, this implicit reference behavior doesn't work for enum-to-namespace interactions and attempting to do this with a namespace-to-enum interaction causes the TypeScript compiler itself to crash. Here is an example of how the TypeScript compiler behaves in each case:

    // "b" is accessible
    enum a { b = 1 }
    enum a { c = b }
    // "e" is accessible
    namespace d { export let e = 1 }
    namespace d { export let f = e }
    // "h" is inaccessible
    enum g { h = 1 }
    namespace g { export let i = h }
    // This causes the TypeScript compiler to crash
    namespace j { export let k = 1 }
    enum j { l = k }

    This release changes the implicit sibling scope lookup behavior to only work for enum-to-enum and namespace-to-namespace interactions. These implicit references no longer work with enum-to-namespace and namespace-to-enum interactions, which should more accurately match the behavior of the TypeScript compiler.

  • Add semicolon insertion before TypeScript-specific definite assignment assertion modifier (#1810)

    TypeScript lets you add a ! after a variable declaration to bypass TypeScript's definite assignment analysis:

    let x!: number[];
    initialize();
    x.push(4);
    function initialize() { x = [0, 1, 2, 3]; }

    This ! is called a definite assignment assertion and tells TypeScript to assume that the variable has been initialized somehow. However, JavaScript's automatic semicolon insertion rules should be able to insert a semicolon before it:

    let a
    !function(){}()

    Previously the above code was incorrectly considered a syntax error in TypeScript. With this release, this code is now parsed correctly.

... (truncated)

Commits
  • 470c38e publish 0.14.1 to npm
  • 2586e4f fill out cli error help text
  • 55cc071 update the default log limit in the help text
  • 90f3449 enable tests that should have been enabled
  • cd6c890 default cli log level: 10 => 6
  • ab92f87 more error message adjustments
  • 63cca7f add a friendly error message for jsx in js
  • 9ec5c57 better missing comma errors in enum
  • 32b3c36 show inlined enum names as comments
  • e1bb432 Overhaul log message formatting (#1811)
  • Additional commits viewable in compare view

Dependabot compatibility score

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.


Dependabot commands and options

You can trigger Dependabot actions by commenting on this PR:

  • @dependabot rebase will rebase this PR
  • @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
  • @dependabot merge will merge this PR after your CI passes on it
  • @dependabot squash and merge will squash and merge this PR after your CI passes on it
  • @dependabot cancel merge will cancel a previously requested merge and block automerging
  • @dependabot reopen will reopen this PR if it is closed
  • @dependabot close will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually
  • @dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
  • @dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
  • @dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)

Bumps [esbuild](https://github.com/evanw/esbuild) from 0.14.0 to 0.14.1.
- [Release notes](https://github.com/evanw/esbuild/releases)
- [Changelog](https://github.com/evanw/esbuild/blob/master/CHANGELOG.md)
- [Commits](evanw/esbuild@v0.14.0...v0.14.1)

---
updated-dependencies:
- dependency-name: esbuild
  dependency-type: direct:production
  update-type: version-update:semver-patch
...

Signed-off-by: dependabot[bot] <support@github.com>
@dependabot dependabot bot added dependencies Pull requests that update a dependency file javascript Pull requests that update Javascript code labels Nov 30, 2021
@dependabot dependabot bot requested a review from ahnpnl November 30, 2021 22:04
@coveralls
Copy link

coveralls commented Nov 30, 2021

Pull Request Test Coverage Report for Build 1523106898

  • 0 of 0 changed or added relevant lines in 0 files are covered.
  • No unchanged relevant lines lost coverage.
  • Overall coverage remained the same at 94.076%

Totals Coverage Status
Change from base Build 1521870009: 0.0%
Covered Lines: 1168
Relevant Lines: 1196

💛 - Coveralls

@ahnpnl ahnpnl merged commit 53f5d5d into main Dec 1, 2021
@dependabot dependabot bot deleted the dependabot/npm_and_yarn/esbuild-0.14.1 branch December 1, 2021 05:39
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
dependencies Pull requests that update a dependency file javascript Pull requests that update Javascript code
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants