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): bump github.com/evanw/esbuild from 0.8.46 to 0.8.55 #447

Conversation

dependabot[bot]
Copy link

@dependabot dependabot bot commented on behalf of github Mar 4, 2021

Bumps github.com/evanw/esbuild from 0.8.46 to 0.8.55.

Release notes

Sourced from github.com/evanw/esbuild's releases.

v0.8.55

  • Align more closely with node's default import behavior for CommonJS (#532)

    Note: This could be considered a breaking change or a bug fix depending on your point of view.

    Importing a CommonJS file into an ESM file does not behave the same everywhere. Historically people compiled their ESM code into CommonJS using Babel before ESM was supported natively. More recently, node has made it possible to use ESM syntax natively but to still import CommonJS files into ESM. These behave differently in many ways but one of the most unfortunate differences is how the default export is handled.

    When you import a normal CommonJS file, both Babel and node agree that the value of module.exports should be stored in the ESM import named default. However, if the CommonJS file used to be an ESM file but was compiled into a CommonJS file, Babel will set the ESM import named default to the value of the original ESM export named default while node will continue to set the ESM import named default to the value of module.exports. Babel detects if a CommonJS file used to be an ESM file by the presence of the exports.__esModule = true marker.

    This is unfortunate because it means there is no general way to make code work with both ecosystems. With Babel the code import * as someFile from './some-file' can access the original default export with someFile.default but with node you need to use someFile.default.default instead. Previously esbuild followed Babel's approach but starting with this release, esbuild will now try to use a blend between the Babel and node approaches.

    This is the new behavior: importing a CommonJS file will set the default import to module.exports in all cases except when module.exports.__esModule && "default" in module.exports, in which case it will fall through to module.exports.default. In other words: in cases where the default import was previously undefined for CommonJS files when exports.__esModule === true, the default import will now be module.exports. This should hopefully keep Babel cross-compiled ESM code mostly working but at the same time now enable some node-oriented code to start working.

    If you are authoring a library using ESM but shipping it as CommonJS, the best way to avoid this mess is to just never use default exports in ESM. Only use named exports with names other than default.

  • Fix bug when ESM file has empty exports and is converted to CommonJS (#910)

    A file containing the contents export {} is still considered to be an ESM file even though it has no exports. However, if a file containing this edge case is converted to CommonJS internally during bundling (e.g. when it is the target of require()), esbuild failed to mark the exports symbol from the CommonJS wrapping closure as used even though it is actually needed. This resulted in an output file that crashed when run. The exports symbol is now considered used in this case, so the bug has been fixed.

  • Avoid introducing this for imported function calls

    It is possible to import a function exported by a CommonJS file into an ESM file like this:

    import {fn} from './cjs-file.js'
    console.log(fn())

    When you do this, esbuild currently transforms your code into something like this:

    var cjs_file = __toModule(require("./cjs-file.js"));
    console.log(cjs_file.fn());

    However, doing that changes the value of this observed by the export fn. The property access cjs_file.fn is in the syntactic "call target" position so the value of this becomes the value of cjs_file. With this release, esbuild will now use a different syntax in this case to avoid passing cjs_file as this:

    var cjs_file = __toModule(require("./cjs-file.js"));
    console.log((0, cjs_file.fn)());

    This change in esbuild mirrors a similar recent TypeScript compiler change, and also makes esbuild more consistent with Babel which already does this transformation.

v0.8.54

  • Fix ordering issue with private class methods (#901)

    This release fixes an ordering issue with private class fields where private methods were not available inside class field initializers. The issue affected code such as the following when the compilation target was set to es2020 or lower:

... (truncated)

Changelog

Sourced from github.com/evanw/esbuild's changelog.

0.8.55

  • Align more closely with node's default import behavior for CommonJS (#532)

    Note: This could be considered a breaking change or a bug fix depending on your point of view.

    Importing a CommonJS file into an ESM file does not behave the same everywhere. Historically people compiled their ESM code into CommonJS using Babel before ESM was supported natively. More recently, node has made it possible to use ESM syntax natively but to still import CommonJS files into ESM. These behave differently in many ways but one of the most unfortunate differences is how the default export is handled.

    When you import a normal CommonJS file, both Babel and node agree that the value of module.exports should be stored in the ESM import named default. However, if the CommonJS file used to be an ESM file but was compiled into a CommonJS file, Babel will set the ESM import named default to the value of the original ESM export named default while node will continue to set the ESM import named default to the value of module.exports. Babel detects if a CommonJS file used to be an ESM file by the presence of the exports.__esModule = true marker.

    This is unfortunate because it means there is no general way to make code work with both ecosystems. With Babel the code import * as someFile from './some-file' can access the original default export with someFile.default but with node you need to use someFile.default.default instead. Previously esbuild followed Babel's approach but starting with this release, esbuild will now try to use a blend between the Babel and node approaches.

    This is the new behavior: importing a CommonJS file will set the default import to module.exports in all cases except when module.exports.__esModule && "default" in module.exports, in which case it will fall through to module.exports.default. In other words: in cases where the default import was previously undefined for CommonJS files when exports.__esModule === true, the default import will now be module.exports. This should hopefully keep Babel cross-compiled ESM code mostly working but at the same time now enable some node-oriented code to start working.

    If you are authoring a library using ESM but shipping it as CommonJS, the best way to avoid this mess is to just never use default exports in ESM. Only use named exports with names other than default.

  • Fix bug when ESM file has empty exports and is converted to CommonJS (#910)

    A file containing the contents export {} is still considered to be an ESM file even though it has no exports. However, if a file containing this edge case is converted to CommonJS internally during bundling (e.g. when it is the target of require()), esbuild failed to mark the exports symbol from the CommonJS wrapping closure as used even though it is actually needed. This resulted in an output file that crashed when run. The exports symbol is now considered used in this case, so the bug has been fixed.

  • Avoid introducing this for imported function calls

    It is possible to import a function exported by a CommonJS file into an ESM file like this:

    import {fn} from './cjs-file.js'
    console.log(fn())

    When you do this, esbuild currently transforms your code into something like this:

    var cjs_file = __toModule(require("./cjs-file.js"));
    console.log(cjs_file.fn());

    However, doing that changes the value of this observed by the export fn. The property access cjs_file.fn is in the syntactic "call target" position so the value of this becomes the value of cjs_file. With this release, esbuild will now use a different syntax in this case to avoid passing cjs_file as this:

    var cjs_file = __toModule(require("./cjs-file.js"));
    console.log((0, cjs_file.fn)());

    This change in esbuild mirrors a similar recent TypeScript compiler change, and also makes esbuild more consistent with Babel which already does this transformation.

0.8.54

  • Fix ordering issue with private class methods (#901)

    This release fixes an ordering issue with private class fields where private methods were not available inside class field initializers. The issue affected code such as the following when the compilation target was set to es2020 or lower:

... (truncated)

Commits
  • 40ff39e publish 0.8.55 to npm
  • f578d5d mix babel and node semantics for "default" (#532)
  • 2eeb8b4 fix #532: use node's "default" semantics for cjs-in-esm
  • ba6fa74 avoid changing "this" for imported function calls
  • 54ef111 fix #910: esm "export {}" must still use cjs "exports"
  • b27d5a9 publish 0.8.54 to npm
  • 0b60424 ci: import relative path to work around windows
  • 2a371b6 warn about direct "eval" in an esm file
  • ae56ba8 don't assume direct eval can access imports
  • 4e1f535 fix #899: cross-chunk import paths
  • 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)

Unverified

This commit is not signed, but one or more authors requires that any commit attributed to them is signed.
Bumps [github.com/evanw/esbuild](https://github.com/evanw/esbuild) from 0.8.46 to 0.8.55.
- [Release notes](https://github.com/evanw/esbuild/releases)
- [Changelog](https://github.com/evanw/esbuild/blob/master/CHANGELOG.md)
- [Commits](evanw/esbuild@v0.8.46...v0.8.55)

Signed-off-by: dependabot[bot] <[email protected]>
@dependabot dependabot bot added the dependencies Pull requests that update a dependency file label Mar 4, 2021
@dependabot @github
Copy link
Author

dependabot bot commented on behalf of github Mar 8, 2021

Superseded by #450.

@dependabot dependabot bot closed this Mar 8, 2021
@dependabot dependabot bot deleted the dependabot/go_modules/github.com/evanw/esbuild-0.8.55 branch March 8, 2021 09:09
@github-actions
Copy link

github-actions bot commented Mar 9, 2022

This pull request has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.

@github-actions github-actions bot locked as resolved and limited conversation to collaborators Mar 9, 2022
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
dependencies Pull requests that update a dependency file
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

0 participants