react-packager: Switch from Q to Bluebird as promises library

[pilwon]

This PR improves performance of react-packager by switching the promises library from the Q to Bluebird.

Here is the test result showing a noticeable difference. (2x speed improvement)

Please refer to this issue for more details.

[pilwon]

Jest is not running on my machine for some reason. Let me fix it and see where the test fails. (Jest doesn't run on Node.js v0.12...)

It turns out code works fine but Jest gets confused with bluebird. (blocker issue: jestjs/jest#90)

@petkaantonovJest works with Q but not with bluebird. Do we have a solution for this?

[amasad]

ok, I think I can fix the jest error (or at least hack around it). I'll work on pulling this

[amasad]

Tested on internal source (which is considerably larger) and this yields a consistent 30% speedup. Great job! I'll sync the changes here soon.

[pilwon]

@amasad 30% speedup sounds beyond awesome. I have a feeling a lot of folks will enjoy the speed improvement with this update ✨😀👍

Btw, I noticed promisify() is the only non-ES6 standard promises feature used in DependencyGraph. Not sure about the other modules but if the use of promises library can be kept to minimum like that we may want to search for an even better alternative. (Bluebird is still my No.1 choice but you never know...)

[pilwon]

@amasad Updated all code to use bluebird. q is completely dropped. (even removed from package.json) Passed all tests.

[amasad]

I already updated that internally :) I should've mentioned that

[amasad]

I just need to sync from our internal repo. Our tools are not in a great place now, but we can't merge pull requests directly from github we have to go through internal review process

[pilwon]

@amasad Understood. FB's merge policy between the internal code and react-native was not clear to me even after reading this section.

Will FB always update its internal code first then bring the changes back to react-native after? This means PRs cannot be directly merged to react-native that is usually the only repo external contributors have access to. I can see the benefits of this merge strategy, such as the quality of contributed code is guaranteed with FB's internal review process (I assume FB has a great one) and code consistency can be easily achieved. As long as there isn't much delay until a PR makes its way back to react-native I am okay with it.

If this is the case though, please add more information to CONTRIBUTING.md so all contributors who send PR clearly understand the merge policy. Thanks-

[vjeux]

@pilwon we want to eventually be github first but are not ready yet. For the time being, we need to ensure that every pull request passes our internal test suites and don't break our internal apps. Good idea about updating the contributing.md file

[sahrens]

Merged internally and synced.