chore(deps): update dependency esbuild to v0.14.27 #1678

renovate · 2022-03-14T22:05:31Z

renovate commented

2022-03-14 22:05:31 +00:00

This PR contains the following updates:

Package	Type	Update	Change
esbuild	devDependencies	patch	`0.14.26` -> `0.14.27`

Release Notes

evanw/esbuild

`v0.14.27`

Compare Source

Avoid generating an enumerable default import for CommonJS files in Babel mode (#2097)

Importing a CommonJS module into an ES module can be done in two different ways. In node mode the default import is always set to module.exports, while in Babel mode the default import passes through to module.exports.default instead. Node mode is triggered when the importing file ends in .mjs, has type: "module" in its package.json file, or the imported module does not have a __esModule marker.

Previously esbuild always created the forwarding default import in Babel mode, even if module.exports had no property called default. This was problematic because the getter named default still showed up as a property on the imported namespace object, and could potentially interfere with code that iterated over the properties of the imported namespace object. With this release the getter named default will now only be added in Babel mode if the default property exists at the time of the import.
Fix a circular import edge case regarding ESM-to-CommonJS conversion (#1894, #2059)

This fixes a regression that was introduced in version 0.14.5 of esbuild. Ever since that version, esbuild now creates two separate export objects when you convert an ES module file into a CommonJS module: one for ES modules and one for CommonJS modules. The one for CommonJS modules is written to module.exports and exported from the file, and the one for ES modules is internal and can be accessed by bundling code that imports the entry point (for example, the entry point might import itself to be able to inspect its own exports).

The reason for these two separate export objects is that CommonJS modules are supposed to see a special export called __esModule which indicates that the module used to be an ES module, while ES modules are not supposed to see any automatically-added export named __esModule. This matters for real-world code both because people sometimes iterate over the properties of ES module export namespace objects and because some people write ES module code containing their own exports named __esModule that they expect other ES module code to be able to read.

However, this change to split exports into two separate objects broke ES module re-exports in the edge case where the imported module is involved in an import cycle. This happened because the CommonJS module.exports object was no longer mutated as exports were added. Instead it was being initialized at the end of the generated file after the import statements to other modules (which are converted into require() calls). This release changes module.exports initialization to happen earlier in the file and then double-writes further exports to both the ES module and CommonJS module export objects.

This fix was contributed by @indutny.

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 Renovate Bot.

This PR contains the following updates: | Package | Type | Update | Change | |---|---|---|---| | [esbuild](https://github.com/evanw/esbuild) | devDependencies | patch | [`0.14.26` -> `0.14.27`](https://renovatebot.com/diffs/npm/esbuild/0.14.26/0.14.27) | --- ### Release Notes <details> <summary>evanw/esbuild</summary> ### [`v0.14.27`](https://github.com/evanw/esbuild/blob/master/CHANGELOG.md#01427) [Compare Source](https://github.com/evanw/esbuild/compare/v0.14.26...v0.14.27) - Avoid generating an enumerable `default` import for CommonJS files in Babel mode ([#2097](https://github.com/evanw/esbuild/issues/2097)) Importing a CommonJS module into an ES module can be done in two different ways. In node mode the `default` import is always set to `module.exports`, while in Babel mode the `default` import passes through to `module.exports.default` instead. Node mode is triggered when the importing file ends in `.mjs`, has `type: "module"` in its `package.json` file, or the imported module does not have a `__esModule` marker. Previously esbuild always created the forwarding `default` import in Babel mode, even if `module.exports` had no property called `default`. This was problematic because the getter named `default` still showed up as a property on the imported namespace object, and could potentially interfere with code that iterated over the properties of the imported namespace object. With this release the getter named `default` will now only be added in Babel mode if the `default` property exists at the time of the import. - Fix a circular import edge case regarding ESM-to-CommonJS conversion ([#1894](https://github.com/evanw/esbuild/issues/1894), [#2059](https://github.com/evanw/esbuild/pull/2059)) This fixes a regression that was introduced in version 0.14.5 of esbuild. Ever since that version, esbuild now creates two separate export objects when you convert an ES module file into a CommonJS module: one for ES modules and one for CommonJS modules. The one for CommonJS modules is written to `module.exports` and exported from the file, and the one for ES modules is internal and can be accessed by bundling code that imports the entry point (for example, the entry point might import itself to be able to inspect its own exports). The reason for these two separate export objects is that CommonJS modules are supposed to see a special export called `__esModule` which indicates that the module used to be an ES module, while ES modules are not supposed to see any automatically-added export named `__esModule`. This matters for real-world code both because people sometimes iterate over the properties of ES module export namespace objects and because some people write ES module code containing their own exports named `__esModule` that they expect other ES module code to be able to read. However, this change to split exports into two separate objects broke ES module re-exports in the edge case where the imported module is involved in an import cycle. This happened because the CommonJS `module.exports` object was no longer mutated as exports were added. Instead it was being initialized at the end of the generated file after the import statements to other modules (which are converted into `require()` calls). This release changes `module.exports` initialization to happen earlier in the file and then double-writes further exports to both the ES module and CommonJS module export objects. This fix was contributed by [@indutny](https://github.com/indutny). </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, click this checkbox. --- This PR has been generated by [Renovate Bot](https://github.com/renovatebot/renovate).

renovate added the

dependencies

label 2022-03-14 22:05:31 +00:00

frederick commented

2022-03-14 22:09:00 +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://1678-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://1678-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.

renovate force-pushed renovate/esbuild-0.x from 3022c16094 to f742c5dcd5

2022-03-15 13:06:51 +00:00

Compare

konrad merged commit 1d9fef9172 into main

2022-03-15 13:24:55 +00:00

konrad deleted branch renovate/esbuild-0.x

2022-03-15 13:24:56 +00:00

konrad referenced this issue from a commit

2022-03-15 13:24:56 +00:00

chore(deps): update dependency esbuild to v0.14.27 (#1678)

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

No reviewers