Skip to content

Replace deprecated Rollup option 'legacy' with custom plugin. #13356

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

Closed
wants to merge 4 commits into from

Conversation

elas7
Copy link
Contributor

@elas7 elas7 commented Aug 9, 2018

The legacy option was added to the Rollup build system (for www builds) in #11469 because the internal transforms break on getters. As of version 0.60.0 of Rollup, legacy support is removed (source, changelog). This PR adds a custom Rollup plugin to replicate the legacy behaviour.

Note that the legacy option performed several transformations to support IE8. The custom Rollup plugin only replicates the replacement of getters (original code here).

Also note that getters are only generated in a very specific case by Rollup. That is, when doing namespace imports (import * as name from 'origin') and one of the imported variables is reassigned at some point (an example of this can be found in the old Rollup tests). At this time, the only getter generated by React code is ReactDOMEventListener._enabled.

The `legacy` option was added to the Rollup build system (for www builds) in facebook#11469 because the internal transforms break on getters. As of version 0.60.0 of Rollup, `legacy` support is removed ([source](rollup/rollup#2141), [changelog](https://github.com/rollup/rollup/blob/master/CHANGELOG.md#0600)). This PR adds a custom Rollup plugin to replicate the `legacy` behaviour.

Note that the `legacy` option preformed several transformations to support IE8. The custom Rollup plugin only replicates the replacement of getters ([original code here](https://github.com/rollup/rollup/blob/349677ceee9d4bbccb5b2f72e653270cb2b0ce51/src/ast/variables/NamespaceVariable.ts#L63)).

Also note that getters are only generated in a very specific case by Rollup. That is, when doing namespace imports (`import * as name from 'origin'`) and one of the imported variables is reassigned at some point (an example of this can be found in the [old Rollup tests](https://github.com/rollup/rollup/tree/349677ceee9d4bbccb5b2f72e653270cb2b0ce51/test/form/samples/legacy-getter)). At this time, the only getter generated by React code is `ReactDOMEventListener._enabled`.
@gaearon
Copy link
Collaborator

gaearon commented Aug 9, 2018

Seems brittle.
Can we run a final Babel pass instead on the final bundle to just transform the getters?

@TrySound
Copy link
Contributor

TrySound commented Aug 9, 2018

@gaearon Is this still relevant for fb build? In #13321 I just removed this option.

@gaearon
Copy link
Collaborator

gaearon commented Aug 9, 2018

Might be relevant. I haven't checked but I also don't have reasons to believe it got fixed.

@elas7
Copy link
Contributor Author

elas7 commented Aug 9, 2018

@gaearon Currently Babel runs before Rollup, but I'll try to add a new Babel pass after the Rollup bundle to remove the getters.

@gaearon
Copy link
Collaborator

gaearon commented Aug 9, 2018

Yeah. Just for FB bundle, and just with that single transform.

The Babel plugin is added in a new Babel pass after the Rollup bundle.

Note that running Babel after Rollup adds an indentation level because of the `if (__DEV__)` wrapper.
@gaearon
Copy link
Collaborator

gaearon commented Aug 10, 2018

Is there a reason we're not using some stock Babel transform for compiling getters according to the spec?

],
};
const result = babelCore.transform(bundleCode, babelOptions);
fs.writeFileSync(mainOutputPath, result.code, 'utf8');
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think running babel inside transformBundle without extra read/write would be a better idea.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@TrySound sounds good to me. I can make that change.

@gaearon are you ok with that?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@TrySound done

@elas7
Copy link
Contributor Author

elas7 commented Aug 10, 2018

@gaearon because there is no stock Babel plugin to convert getters to ES3 (source)

@Simek
Copy link
Contributor

Simek commented Aug 10, 2018

@elas7
Copy link
Contributor Author

elas7 commented Aug 10, 2018

@Simek Sadly I can't use that unofficial plugin because it only transforms Object.defineProperty() getters, and those are not the kind of getters generated by Rollup.

Thanks, though.

This is more efficient because we don't have to do an extra read/write.
Copy link
Collaborator

@gaearon gaearon left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'll see if we can fix it on our side instead. Left some nits

const keyNode = path.node.key;
const isValidKey = t.isIdentifier(keyNode);
if (!isValidKey) {
return;
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can we throw here instead?

t.isReturnStatement(bodyNode.body[0]) &&
t.isIdentifier(bodyNode.body[0].argument);
if (!isValidBody) {
return;
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Here too.

@stale
Copy link

stale bot commented Jan 10, 2020

This pull request has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contribution.

@stale stale bot added the Resolution: Stale Automatically closed due to inactivity label Jan 10, 2020
@stale
Copy link

stale bot commented Jan 17, 2020

Closing this pull request after a prolonged period of inactivity. If this issue is still present in the latest release, please ask for this pull request to be reopened. Thank you!

@stale stale bot closed this Jan 17, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
CLA Signed Resolution: Stale Automatically closed due to inactivity
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants