Convert React Native builds to named exports

[sebmarkbage]

These don't need any forks because we always export the same things atm.
They still build to CJS though atm.

[codesandbox-ci]

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 6930f7c:

Sandbox	Source
blissful-khorana-ncl9v	Configuration

[sebmarkbage]

Diff sebmarkbage/react-builds@f4ed2aa

[sizebot]

Details of bundled changes.

Comparing: 60016c4...6930f7c

react-native-renderer

File	Filesize Diff	Gzip Diff	Prev Size	Current Size	Prev Gzip	Current Gzip	ENV
ReactFabric-dev.js	-0.1%	-0.2%	615.82 KB	615.37 KB	132.76 KB	132.52 KB	RN_FB_DEV
ReactFabric-prod.js	-0.1%	-0.2%	253.25 KB	252.87 KB	43.91 KB	43.81 KB	RN_FB_PROD
ReactNativeRenderer-dev.js	-0.0%	-0.1%	630.69 KB	630.47 KB	136.53 KB	136.42 KB	RN_OSS_DEV
ReactFabric-profiling.js	-0.1%	-0.2%	264.41 KB	264.02 KB	46.03 KB	45.94 KB	RN_FB_PROFILING
ReactNativeRenderer-prod.js	-0.1%	-0.1%	260.95 KB	260.62 KB	45.25 KB	45.22 KB	RN_OSS_PROD
ReactNativeRenderer-profiling.js	-0.1%	-0.1%	272.12 KB	271.77 KB	47.38 KB	47.35 KB	RN_OSS_PROFILING
ReactNativeRenderer-dev.js	-0.0%	-0.1%	633.66 KB	633.45 KB	136.92 KB	136.81 KB	RN_FB_DEV
ReactNativeRenderer-prod.js	-0.1%	-0.1%	261.34 KB	261.01 KB	45.31 KB	45.28 KB	RN_FB_PROD
ReactNativeRenderer-profiling.js	-0.1%	-0.1%	272.5 KB	272.16 KB	47.44 KB	47.41 KB	RN_FB_PROFILING
ReactFabric-dev.js	-0.1%	-0.2%	612.94 KB	612.48 KB	132.38 KB	132.14 KB	RN_OSS_DEV
ReactFabric-prod.js	-0.1%	-0.2%	252.9 KB	252.52 KB	43.82 KB	43.73 KB	RN_OSS_PROD
ReactFabric-profiling.js	-0.1%	-0.2%	264.07 KB	263.68 KB	45.96 KB	45.87 KB	RN_OSS_PROFILING

Size changes (experimental)

Generated by 🚫 dangerJS against 6930f7c

[sizebot]

Details of bundled changes.

Comparing: 60016c4...6930f7c

react-native-renderer

File	Filesize Diff	Gzip Diff	Prev Size	Current Size	Prev Gzip	Current Gzip	ENV
ReactNativeRenderer-prod.js	-0.1%	-0.1%	260.94 KB	260.61 KB	45.24 KB	45.21 KB	RN_OSS_PROD
ReactNativeRenderer-profiling.js	-0.1%	-0.1%	272.11 KB	271.76 KB	47.37 KB	47.34 KB	RN_OSS_PROFILING
ReactFabric-dev.js	-0.1%	-0.2%	612.93 KB	612.47 KB	132.37 KB	132.13 KB	RN_OSS_DEV
ReactFabric-prod.js	-0.1%	-0.2%	252.89 KB	252.51 KB	43.81 KB	43.72 KB	RN_OSS_PROD
ReactFabric-profiling.js	-0.1%	-0.2%	264.05 KB	263.67 KB	45.95 KB	45.86 KB	RN_OSS_PROFILING
ReactNativeRenderer-dev.js	-0.0%	-0.1%	630.67 KB	630.46 KB	136.53 KB	136.42 KB	RN_OSS_DEV

Size changes (stable)

Generated by 🚫 dangerJS against 6930f7c

[elicwhite]

I’m not exactly sure from your summary what the change is here or what the purpose is. However, the resulting diff you linked seems fine if export syntax works, so that’s fine with me. Having a test plan that sanity checks that this build still works in the Facebook app would be great though!

[elicwhite]

I think we still need to export an empty object here so that it matches the paper renderer. Of code reads a key off and checks if the value is defined, that would now throw in fabric right because the object would be undefined?

[sebmarkbage]

The one current caller doesn't check if it's defined.

https://github.com/facebook/react-native/blob/master/Libraries/Utilities/JSDevSupportModule.js#L23-L24

And we're not going to be adding this back. No more internals.

[sebmarkbage]

There's some more info in #18106

I think in a follow up I'll actually convert this to ES modules. Not sure if RN can take advantage of it though since it's a huge mix of ES modules and requires.

Having a test plan that sanity checks that this build still works in the Facebook app would be great though!

That's what the sync is for. We'll find out. :)

[elicwhite]

That's what the sync is for. We'll find out. :)

That puts the burden on someone else, at some point in the future which would require them identifying this is the problem, and reverting it. However, reverting it probably wouldn't be trivial with additional changes stacked on top. Also, once this lands all partial syncs will have conflicts so we'd be totally blocked on moving forward until it can be resolved.

Doing a test sync of a change like this and verifying that the change works seems like something that should be done before merging.

[sebmarkbage]

That puts the burden on someone else, at some point in the future which would require them identifying this is the problem, and reverting it. However, reverting it probably wouldn't be trivial with additional changes stacked on top. Also, once this lands all partial syncs will have conflicts so we'd be totally blocked on moving forward until it can be resolved.

I mean this is literally the point of the sync. To batch that burden on someone else. Every other thing we land has that problem.

[gaearon]

I'll take the burden. :-)