Skip to content

Check in a forked version of object-assign only for UMD builds #18180

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

Merged
merged 2 commits into from
Feb 28, 2020

Conversation

sebmarkbage
Copy link
Collaborator

@sebmarkbage sebmarkbage commented Feb 28, 2020

This one uses ES modules so that we can inline it into UMD builds.

We could wait for object-assign to make an ESM export but we're going to remove this dependency and assume global polyfills in the next version anyway. However, we'd have to figure out how to keep the copyright header and it'll get counted in terms of byte size (even if other tooling removes it).

A lot of headache when we have our own implementation anyway. So I'll just use that.

Ours is not resilient to checking certain browser bugs but those browsers are mostly unused anyway. (Even FB breaks on them presumably.)

We also don't need to be resilient to Symbols since the way React uses it we shouldn't need to copy symbols

@sebmarkbage sebmarkbage requested a review from gaearon February 28, 2020 17:50
@facebook-github-bot facebook-github-bot added CLA Signed React Core Team Opened by a member of the React Core Team labels Feb 28, 2020
@codesandbox-ci
Copy link

codesandbox-ci bot commented Feb 28, 2020

This pull request is automatically built and testable in CodeSandbox.

To see build info of the built libraries, click here or the icon next to each commit SHA.

Latest deployment of this branch, based on commit c9ebd39:

Sandbox Source
cranky-herschel-lq6cy Configuration

Copy link
Contributor

@threepointone threepointone left a comment

Choose a reason for hiding this comment

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

slightly related, we have an open issue about including the license banner in prod builds #17492

@sebmarkbage
Copy link
Collaborator Author

sebmarkbage commented Feb 28, 2020

I'll just take one of our own implementations then. Probably easier than figuring out the banner and saves bytes.

@sizebot
Copy link

sizebot commented Feb 28, 2020

Details of bundled changes.

Comparing: 4ee592e...c9ebd39

react

File Filesize Diff Gzip Diff Prev Size Current Size Prev Gzip Current Gzip ENV
react.development.js -1.5% -2.2% 103.46 KB 101.88 KB 25.4 KB 24.86 KB UMD_DEV
react.production.min.js -4.6% -4.7% 12.6 KB 12.02 KB 4.91 KB 4.68 KB UMD_PROD
react.profiling.min.js -3.6% -3.7% 16.14 KB 15.56 KB 6.01 KB 5.79 KB UMD_PROFILING

React: size: -4.6%, gzip: -4.7%

Size changes (experimental)

Generated by 🚫 dangerJS against c9ebd39

@sizebot
Copy link

sizebot commented Feb 28, 2020

Warnings
⚠️ Failed to fetch build artifacts for base commit: 4ee592e

Size changes (stable)

Generated by 🚫 dangerJS against c9ebd39

@sebmarkbage sebmarkbage force-pushed the checkinobjectassign branch 2 times, most recently from 8b22fbc to f727b1d Compare February 28, 2020 18:14
This one uses ES modules so that we can inline it into UMD builds.

We could wait for object-assign to make an ESM export but we're going to
remove this dependency and assume global polyfills in the next version
anyway. However, we'd have to figure out how to keep the copyright header
and it'll get counted in terms of byte size (even if other tooling removes
it).

A lot of headache when we have our own implementation anyway. So I'll just
use that.

Ours is not resilient to checking certain browser bugs but those browsers
are mostly unused anyway. (Even FB breaks on them presumably.)

We also don't need to be resilient to Symbols since the way React uses it
we shouldn't need to copy symbols
export default Object.assign ||
function(target, sources) {
if (target == null) {
throw new TypeError('Object.assign target cannot be null or undefined');
Copy link
Collaborator

Choose a reason for hiding this comment

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

Do we actually care about this? Would we expect to ever happen with our usage?

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

Maybe if it's a bug. Meh. I mostly just took it as-is from FB.

The polyfill needs to be able to feature detect Object.assign.
@@ -28,6 +28,10 @@ module.exports = function autoImporter(babel) {

visitor: {
CallExpression: function(path, file) {
if (file.filename.indexOf('object-assign') !== -1) {
// Don't replace Object.assign if we're transforming object-assign
return;
Copy link
Collaborator Author

Choose a reason for hiding this comment

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

Since we're now transforming the file itself, I needed to ensure this bails out.

@sebmarkbage
Copy link
Collaborator Author

Tested fixtured and ensured that it conditionally picks up the native version.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
CLA Signed React Core Team Opened by a member of the React Core Team
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants