Revisting: Remove Haste from Libraries/ and convert to relative requires to shrink bundle sizes

[rdy]

Hi, I would like to revisit the issue of removing the use of haste modules as described by issue #14196.

I have been able to get a bundle size reduction of react-native using webpack with haul. My approach relies on the modules not using haste so that webpack can properly identify dead code.

I've put together a code example using create-react-native-app ejected you can see it here:
https://github.com/rdy/tree-shaking-example/tree/tree-shaking. I've chosen to use the android platform since I had the build tools on my machine already. You can build the bundles from the package.json scripts bundle:metro and bundle:haul.

The master branch contains a version where I've optimized the bundle size with haul slightly by tweaking the babel output instead of relying on react-native-preset.
Metro bundle: 505K
Haul bundle: 538K

The tree-shaking branch shows the changes from that where I've used my fork of react-native that removes haste as well as haul that doesn't use haste anymore. I've provided a transform for babel-plugin-transform-imports. I'm basically looking at the original main for react-native and supplying the correct import path, this allows webpack to be able to tree shake out the dead code.

Haul bundle with tree shaking: 254K

I've created a series of PDF using source-map-explorer to illustrate that pieces of the bundle are actually being remove correctly by webpack.

metro.pdf
haul-pre-shake.pdf
haul-shaken.pdf

I believe that I could fix the problem with a babel-plugin to rewrite the haste modules to relative requires if necessary but it would be better to not have to maintain a fork or have to transform react-native. Is there a compelling reason to keeping haste? The bundle savings show in my example are pretty compelling.

I was able to do everything with off the shelf components. The only changes I've needed to make was removing haste from react-native and haul so that webpack can trim the dead code.

[react-native-bot]

Thanks for posting this! It looks like your issue may be incomplete. Are all the fields required by the Issue Template filled out?

If you believe your issue contains all the relevant information, let us know in order to have a maintainer remove the No Template label. Thank you for your contributions.

_{How to Contribute • What to Expect from Maintainers}

[matthargett]

Cc @skevy @rozele @grabbou
A similar change was merged into Expo here: expo#10

[grabbou]

cc: @thymikee @satya164

[vincentriemer]

Has there been any progress on the action items at the end of #14196? It still seems like this would break react-native-windows.

[kelset]

Thanks for sharing these informations btw - really looking forward about where removing haste could take RN.

(cc @skevy btw which I seem to recall did some work around this)

[rdy]

@vincentriemer I've thought about the comments on how it would work for react-native-windows. In my case I am using webpack so I can do platform mapping directly using alias instead @providesModule. If we wanted we could change it so that when we detect a haste module by its name for example Text could strip out the relative path to Text and perform the same lookup via haste. We'd probably need to make the bundler aware of this difference but it would allow us to mix the relative requires with haste as way to move forward.

[rdy]

@kelset yes, this is a continuation of the work that @skevy already did. I used his script to modify a version of react-native so I could rely on webpack to do the dead code elimination with uglify. The proof of concept works so I thought I would get the discussion going again. Since react has moved away from haste I was wondering if react-native could do the same, provided we still maintained a way for out of tree platforms like windows to still work.

[stale]

Hey there, it looks like there has been no activity on this issue recently. Has the issue been fixed, or does it still require the community's attention? This issue may be closed if no further activity occurs. You may also label this issue as "For Discussion" or "Good first issue" and I will leave it open. Thank you for your contributions.