[Discussion] Moving react-native-packager into a new repository.
cpojer opened this issue · 11 comments
Hey everyone!
The JavaScript Tools team at Facebook, especially @davidaurelio and @jeanlauliac, have made big improvements to react-native-packager's performance and reliability this year so far. As more and more people write JavaScript for mobile applications, it is essential for a bundler to be fast, reliable and scalable.
Here are some of the highlights from this half so far:
- 10x faster source map generation. Read Fast Source Map Generation for React Native.
- Rewrote symbolication from a 10s blocking call to a ~2s async call (b6ca952).
- When adding/removing dependencies, the reload time was reduced from 7 seconds to 4 seconds on large repositories at Facebook.
- Many performance minded improvements (still ways to go!) to improve startup performance. Internally at Facebook, we built a global transform cache with a server that stores all transformed files. This has a public interface, however it requires a separate server implementation in open source – we are happy to give advice if anyone wants to build an open source server component to speed up initial load time for large apps.
Next week we are planning to split react-native-packager off of React Native. We haven't been able to take enough care of open source requests around react-native-packager because of the sheer size of the react-native repository. We know there are a couple of long-standing issues and we'd like to finally address them in a smaller codebase that is easier to contribute to and easier to maintain:
- Make it easier to configure react-native-packager.
- Symlink support.
- Ability to use custom transformations and languages.
What will change as a user of react-native?
Nothing.
What will change for maintainers of the react-native repo?
The new repository will require releases to be lined up with releases of react-native but we aim to make the publishing process simple.
What will change when sending Pull Requests to react-native?
Contributors will have to send pull requests to the new repository for react-native-packager.
What will change for engineers at Facebook?
We aren't changing our current workflow but we may change to use GitHub-first development for react-native-packager in the future.
Please let us know if you have any concerns. The team and I are happy to address them.
Everybody seems to be happy, so I'm closing this. Feel free to comment on this thread if you have further thoughts.
Shouldn't we just keep this open until the migration is done?
I want to start off by saying thanks to you and the rest of the React Native team for all your great work!
I had a quick question, where does the RN team stand with regards to packager alternatives like Haul?
I'm curious if there would be a benefit in there being 1 "blessed" packager that could cater to the community's needs (i.e., symbolic links, latest HMR, Webpack's ecosystem, etc.). Are there features currently in the packager that can't be implemented in Haul? Would it take too long for Haul to reach feature parity with the packager?
I'm curious as to what the RN team's thoughts are on these.
As for my own opinion, being working on packager, I'm happy there are alternatives such as Haul so that the community has more options depending on needs such as symlinks. I believe this is healthy for React Native to have alternative choices.
I think one of the main difference right now is performance, where Metro bundler/packager achieve higher incremental build performance. That makes sense as it's the reason we built it in the first place, but it also explains the limitations such as not supporting symlinks—we depend on watchman, that doesn't support these. That is why I think feature parity is not necessarily achievable or desirable, but that it doesn't mean we can't share a large amount of features and/or code ^_^
My wish is that anyone can break apart the code of packager and reassemble it in different ways so that there are never hard a constraint on what is or isn't possible.
EDIT: btw I stumbled on that old thread, linked from the packager/README.md, that describes the early differentiation: #5
I think it'd be nice to write key this key sentence from here: 'What will change as a user of react-native? Nothing.' on Metro repository readme. I was looking few good minutes for some docs about 'how to switch to metro' :)
The impact on React Native users isn't quite zero — in fact, this is a breaking change.
The iOS pbxproj generated by react-native init includes a 'run script' build step that invokes the following shell command:
export NODE_BINARY=node
../node_modules/react-native/packager/react-native-xcode.sh index.ios.js
Now that /packager is gone and react-native-xcode.sh now lives under /scripts, existing React Native users will have to update the path in this build step.
There's a lot of different PRs and commits supporting this switch, so perhaps I didn't see the Breaking Change announcement. Either way, I strongly recommend you include it in the release notes for 0.46.
tl;dr for other people in search of a solution:
If you're seeing this error during iOS builds...
../node_modules/react-native/packager/react-native-xcode.sh: No such file or directory
...then you need to go into Xcode, click the root of your project, go to 'Build Phases', find the one that says 'React Native', then update the command to point to:
export NODE_BINARY=node
../node_modules/react-native/scripts/react-native-xcode.sh index.ios.js
cc @grabbou – would you mind including this in the Release Notes? We weren't aware that generated files would have full paths.
Makes a lot of sense! We will include those in release notes as soon as we finish working on them :)
That's right! Now should be there :)