Restore compatibility with interopRequireDefault (import Things from 'metro-pkg') in Metro public Node.js APIs.#1565
Closed
robhogan wants to merge 1 commit into
Closed
Restore compatibility with interopRequireDefault (import Things from 'metro-pkg') in Metro public Node.js APIs.#1565robhogan wants to merge 1 commit into
import Things from 'metro-pkg') in Metro public Node.js APIs.#1565robhogan wants to merge 1 commit into
Conversation
meta-cla
Bot
added
the
CLA Signed
Contributor
|
This pull request was exported from Phabricator. Differential Revision: D81127738 |
facebook-github-bot
pushed a commit
that referenced
this pull request
Aug 29, 2025
… 'metro-pkg'`) in Metro public Node.js APIs. (#1565) Summary: In #1549 (Migrate Metro to ESM syntax), which was intended to be non-breaking, there was one use case I overlooked. If your code consuming Metro under Node.js uses ESM-style imports transformed to CommonJS with Babel's default interop mode, you could've written any of: ``` // Import default import Resolver from 'metro-resolver'; Resolver.resolve('./foo'); ``` or, ``` // Import all named as namespace import * as Resolver from 'metro-resolver'; Resolver.resolve('./foo'); ``` or, ``` // Import named import {resolve} from 'metro-resolver'; resolve('./foo'); ``` However, when we switched from a `module.exports` object to ESM-style named exports, the first case would fail, because Babel marks our index file with `__esModule`, which causes `interopRequireDefault` to select the `default` prop (which is now undefined). The consumer would be transformed to this, which would throw: ``` var _metroResolver = _interopRequireDefault(require("metro-resolver")); function _interopRequireDefault(e) { return e && e.__esModule ? e : { default: e }; } _metroResolver.default.resolve('./foo'); // TypeError: Cannot access property resolve of undefined ``` This restores compatibility by adding an explicit default export alongside the named exports, for all public package entry points that were not already `__esModule`s. These will be removed in a future breaking change. Changelog: Internal - fix unreleased breaking change from #1549 Reviewed By: vzaidman Differential Revision: D81127738
facebook-github-bot
force-pushed
the
export-D81127738
branch
from
d136f29 to
57026ff
Compare
Contributor
|
This pull request was exported from Phabricator. Differential Revision: D81127738 |
… 'metro-pkg'`) in Metro public Node.js APIs. (#1565) Summary: In #1549 (Migrate Metro to ESM syntax), which was intended to be non-breaking, there was one use case I overlooked. If your code consuming Metro under Node.js uses ESM-style imports transformed to CommonJS with Babel's default interop mode, you could've written any of: ``` // Import default import Resolver from 'metro-resolver'; Resolver.resolve('./foo'); ``` or, ``` // Import all named as namespace import * as Resolver from 'metro-resolver'; Resolver.resolve('./foo'); ``` or, ``` // Import named import {resolve} from 'metro-resolver'; resolve('./foo'); ``` However, when we switched from a `module.exports` object to ESM-style named exports, the first case would fail, because Babel marks our index file with `__esModule`, which causes `interopRequireDefault` to select the `default` prop (which is now undefined). The consumer would be transformed to this, which would throw: ``` var _metroResolver = _interopRequireDefault(require("metro-resolver")); function _interopRequireDefault(e) { return e && e.__esModule ? e : { default: e }; } _metroResolver.default.resolve('./foo'); // TypeError: Cannot access property resolve of undefined ``` This restores compatibility by adding an explicit default export alongside the named exports, for all public package entry points that were not already `__esModule`s. These will be removed in a future breaking change. Changelog: Internal - fix unreleased breaking change from #1549 Reviewed By: vzaidman Differential Revision: D81127738
facebook-github-bot
force-pushed
the
export-D81127738
branch
from
57026ff to
c682acb
Compare
Contributor
|
This pull request was exported from Phabricator. Differential Revision: D81127738 |
Contributor
facebook-github-bot
pushed a commit
that referenced
this pull request
Aug 29, 2025
… 'metro-pkg'`) in Metro public Node.js APIs. (#1565) Summary: In #1549 (Migrate Metro to ESM syntax), which was intended to be non-breaking, there was one use case I overlooked. If your code consuming Metro under Node.js uses ESM-style imports transformed to CommonJS with Babel's default interop mode, you could've written any of: ``` // Import default import Resolver from 'metro-resolver'; Resolver.resolve('./foo'); ``` or, ``` // Import all named as namespace import * as Resolver from 'metro-resolver'; Resolver.resolve('./foo'); ``` or, ``` // Import named import {resolve} from 'metro-resolver'; resolve('./foo'); ``` However, when we switched from a `module.exports` object to ESM-style named exports, the first case would fail, because Babel marks our index file with `__esModule`, which causes `interopRequireDefault` to select the `default` prop (which is now undefined). The consumer would be transformed to this, which would throw: ``` var _metroResolver = _interopRequireDefault(require("metro-resolver")); function _interopRequireDefault(e) { return e && e.__esModule ? e : { default: e }; } _metroResolver.default.resolve('./foo'); // TypeError: Cannot access property resolve of undefined ``` This restores compatibility by adding an explicit default export alongside the named exports, for all public package entry points that were not already `__esModule`s. These will be removed in a future breaking change. Changelog: Internal - fix unreleased breaking change from #1549 Test Plan: Imported from GitHub, without a `Test Plan:` line. Rollback Plan: Differential Revision: D81127738 Pulled By: robhogan fbshipit-source-id: c4caf30cc75ec7f7f3a87ed8df206c0fa0c58ffd
Contributor
Author
|
This was merged in e7e69b1, I guess the bot missed closing this PR. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary:
In #1549 (Migrate Metro to ESM syntax), which was intended to be non-breaking, there was one use case I overlooked.
If your code consuming Metro under Node.js uses ESM-style imports transformed to CommonJS with Babel's default interop mode, you could've written any of:
or,
or,
However, when we switched from a
module.exportsobject to ESM-style named exports, the first case would fail, because Babel marks our index file with__esModule, which causesinteropRequireDefaultto select thedefaultprop (which is now undefined).The consumer would be transformed to this, which would throw:
This restores compatibility by adding an explicit default export alongside the named exports, for all public package entry points that were not already
__esModules. These will be removed in a future breaking change.Changelog: Internal - fix unreleased breaking change from #1549
Reviewed By: vzaidman
Differential Revision: D81127738