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

import-export-plugin: Rename potentially conflicting declarations at module scope (module, exports, require, global) #1385

Closed
wants to merge 1 commit into from

Conversation

robhogan
Copy link
Contributor

@robhogan robhogan commented Nov 9, 2024

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); // Now prints "{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.

Differential Revision: D65536715

@facebook-github-bot 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
@facebook-github-bot
Copy link
Contributor

This pull request was exported from Phabricator. Differential Revision: D65536715

@facebook-github-bot
Copy link
Contributor

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
Copy link
Contributor

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
@facebook-github-bot
Copy link
Contributor

This pull request was exported from Phabricator. Differential Revision: D65536715

@facebook-github-bot
Copy link
Contributor

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
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants