-
Notifications
You must be signed in to change notification settings - Fork 634
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
import-export-plugin: Rename potentially conflicting declarations at module scope (module, exports, require, global) #1385
Closed
Conversation
This file contains 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
facebook-github-bot
added
the
CLA Signed
This label is managed by the Facebook bot. Authors need to sign the CLA before a PR can be reviewed.
label
Nov 9, 2024
This pull request was exported from Phabricator. Differential Revision: D65536715 |
facebook-github-bot
force-pushed
the
export-D65536715
branch
from
November 10, 2024 13:29
caa9d90
to
ec556dc
Compare
This pull request was exported from Phabricator. Differential Revision: D65536715 |
facebook-github-bot
pushed a commit
that referenced
this pull request
Nov 11, 2024
…module scope (module, exports, require, global) (#1385) Summary: Currently, when using `experimentalImportPlugin` (`import-export-plugin`) without `babel-plugin-transform-module-commonjs`, the following completely legal ESM has broken exports and broken internal behaviour: ``` const exports = {} export const foo = 'bar'; process.nextTick(() => { console.log(exports); // should print "{}" }); ``` Because it transforms to this, where `var exports` does not throw (as `const` or `let` would for an already-bound name) but it does shadow the injected `exports` argument, so that no assignment to the injected `exports` is ever made (in other words, a consumer would see no defined exports). In fact, an assignment to the local `exports` *is* made where it shouldn't be. ``` __d(function (global, require, _$$_IMPORT_DEFAULT, _$$_IMPORT_ALL, module, exports, _$$_METRO_DEPENDENCY_MAP) { "use strict"; Object.defineProperty(exports, '__esModule', { value: true }); var exports = {}; var foo = 'bar'; process.nextTick(() => { console.log(exports); // "{foo: 'bar'}" }); exports.foo = foo; },/*...*/); ``` Moreover, in a configuration where we don't transform `const`/`let` to `var` (eg targeting web or server), this actually throws at runtime, as would binding any of `module`, `global` or `require`. The solution is to rename bindings to names that would be fine in ESM but conflict with CommonJS names / Metro's module factory The analogue in the (roughly) corresponding Babel plugin is here: https://github.com/babel/babel/blob/38d26cd5eeb66b697671cfb8c78f963f02992073/packages/babel-plugin-transform-modules-commonjs/src/index.ts#L198-L204 (Note that we do not inject `__dirname` or `__filename` in Metro, but we do inject `global`) Changelog: ``` **[Fix]**: import-exports-plugin: Rename `module`/`require`/`exports`/`global` declarations to avoid conflicts with injected args or generated code. ``` Reviewed By: huntie Differential Revision: D65536715
facebook-github-bot
force-pushed
the
export-D65536715
branch
from
November 11, 2024 17:13
ec556dc
to
dc5bc25
Compare
This pull request was exported from Phabricator. Differential Revision: D65536715 |
…module scope (module, exports, require, global) (#1385) Summary: Currently, when using `experimentalImportPlugin` (`import-export-plugin`) without `babel-plugin-transform-module-commonjs`, the following completely legal ESM has broken exports and broken internal behaviour: ``` const exports = {} export const foo = 'bar'; process.nextTick(() => { console.log(exports); // should print "{}" }); ``` Because it transforms to this, where `var exports` does not throw (as `const` or `let` would for an already-bound name) but it does shadow the injected `exports` argument, so that no assignment to the injected `exports` is ever made (in other words, a consumer would see no defined exports). In fact, an assignment to the local `exports` *is* made where it shouldn't be. ``` __d(function (global, require, _$$_IMPORT_DEFAULT, _$$_IMPORT_ALL, module, exports, _$$_METRO_DEPENDENCY_MAP) { "use strict"; Object.defineProperty(exports, '__esModule', { value: true }); var exports = {}; var foo = 'bar'; process.nextTick(() => { console.log(exports); // "{foo: 'bar'}" }); exports.foo = foo; },/*...*/); ``` Moreover, in a configuration where we don't transform `const`/`let` to `var` (eg targeting web or server), this actually throws at runtime, as would binding any of `module`, `global` or `require`. The solution is to rename bindings to names that would be fine in ESM but conflict with CommonJS names / Metro's module factory The analogue in the (roughly) corresponding Babel plugin is here: https://github.com/babel/babel/blob/38d26cd5eeb66b697671cfb8c78f963f02992073/packages/babel-plugin-transform-modules-commonjs/src/index.ts#L198-L204 (Note that we do not inject `__dirname` or `__filename` in Metro, but we do inject `global`) Changelog: ``` **[Fix]**: import-exports-plugin: Rename `module`/`require`/`exports`/`global` declarations to avoid conflicts with injected args or generated code. ``` Reviewed By: huntie Differential Revision: D65536715
robhogan
force-pushed
the
export-D65536715
branch
from
November 11, 2024 22:22
dc5bc25
to
5d7503c
Compare
This pull request was exported from Phabricator. Differential Revision: D65536715 |
This pull request has been merged in 578a02d. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Labels
CLA Signed
This label is managed by the Facebook bot. Authors need to sign the CLA before a PR can be reviewed.
fb-exported
Merged
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:
Currently, when using
experimentalImportPlugin
(import-export-plugin
) withoutbabel-plugin-transform-module-commonjs
, the following completely legal ESM has broken exports and broken internal behaviour:Because it transforms to this, where
var exports
does not throw (asconst
orlet
would for an already-bound name) but it does shadow the injectedexports
argument, so that no assignment to the injectedexports
is ever made (in other words, a consumer would see no defined exports). In fact, an assignment to the localexports
is made where it shouldn't be.Moreover, in a configuration where we don't transform
const
/let
tovar
(eg targeting web or server), this actually throws at runtime, as would binding any ofmodule
,global
orrequire
.The solution is to rename bindings to names that would be fine in ESM but conflict with CommonJS names / Metro's module factory
The analogue in the (roughly) corresponding Babel plugin is here: https://github.com/babel/babel/blob/38d26cd5eeb66b697671cfb8c78f963f02992073/packages/babel-plugin-transform-modules-commonjs/src/index.ts#L198-L204
(Note that we do not inject
__dirname
or__filename
in Metro, but we do injectglobal
)Changelog:
Differential Revision: D65536715