Uh oh!
There was an error while loading. Please reload this page.
[RFC] Remove knowledge of fbjs from the packager - #5084
Conversation
facebook-github-bot
commented
Jan 3, 2016
vjeux
commented
Jan 3, 2016
There was a problem hiding this comment.
It's sad that we include a module named CSSCore in rn :(
There was a problem hiding this comment.
We may not need to - I'd be happy to prune. But, I did see that CSSCore was blacklisted from downstream...so I thought there might be a place where you guys are using it internally...which is the only reason these stubs really exist anyway (otherwise we'd require from fbjs everywhere). But, I could be wrong. :)
There was a problem hiding this comment.
Yeah, we have one upstream module requires CSSCore :(
martinbigio
commented
Jan 3, 2016
I LOVE this change! wish one day we could remove |
martinbigio
commented
Jan 3, 2016
What if we have have stubs only internally on Facebook. Otherwise, people on OSS may get confused trying to figure out why we expose both CommonJS and Haste modules for fbjs. |
skevy
commented
Jan 3, 2016
@martinbigio the reason I added the stubs here was after talking to @spicyj. We discussed that it would be a good thing to keep RN code using haste, for consistency throughout the RN codebase. Otherwise...you have |
skevy
commented
Jan 3, 2016
@martinbigio regarding your comment about the tests...for what it's worth, I've run flow and all the tests locally with the fbjs change included (that wasn't an easy task haha)...and the changes required are included in this diff (skevy@7c00d73, skevy@42af07e, skevy@bc4486a). |
martinbigio
commented
Jan 4, 2016
@skevy sounds good. I'll import and test this internally once fbjs#95 lands |
skevy
commented
Jan 4, 2016
🚀 |
skevy
commented
Jan 5, 2016
@martinbigio, just FYI, facebook/fbjs#95 is merged. :-) |
martinbigio
commented
Jan 5, 2016
@facebook-github-bot import |
facebook-github-bot
commented
Jan 5, 2016
Thanks for importing. If you are an FB employee go to https://our.intern.facebook.com/intern/opensource/github/pull_request/461611524028597/int_phab to review. |
davidaurelio
commented
Jan 5, 2016
We might want to keep Promise.js, in order to be able to control warning behavior (for unhandled rejections) |
skevy
commented
Jan 5, 2016
@davidaurelio if we keep Promise, then projects like Relay that import "fbjs/lib/Promise" will break...hence me moving it to fbjs at |
davidaurelio
commented
Jan 6, 2016
I will work around it in |
skevy
commented
Jan 7, 2016
@davidaurelio I saw you updated Promise.js -- I guess I should bring these changes over to fbjs's Promise.native.js? |
skevy
commented
Jan 7, 2016
facebook-github-bot
commented
Jan 7, 2016
@skevy updated the pull request. |
davidaurelio
commented
Jan 8, 2016
@skevy very cool, thank you! I will probably replace this with a configurable hook in the future, so that we don’t leak too much RN specific stuff into fbjs. That should also make stack trace formatting easier. |
skevy
commented
Jan 8, 2016
@davidaurelio that's totally fine, just in lieu of this getting merged (because it involves so many coordinating PRs and infra changes)...I wanted to make sure we were keeping up to date. |
Summary: Turns out, even after discussion that was had in #5294 (comment), we really do need this transform. I've just included it in the preset...let me know if you all would rather publish to npm. The actual reason why this is necessary is because in the latest sync from FB, fbjs was updated to use the `Symbol.iterator` express in it's isEmpty function: facebook/fbjs@064a484 We use this in RN in the ListView...and this change (once #5084 is merged) will cause ListView to break on older JSC context's. This resolves that, and is probably something we should have had all along. Closes#5824 Reviewed By: svcscm Differential Revision: D2913315 Pulled By: vjeux fb-gh-sync-id: abaf484a9431b3111e8118d01db8d2c0d2dd73ca shipit-source-id: abaf484a9431b3111e8118d01db8d2c0d2dd73ca
Summary: This PR moves `react` from dependencies to peerDependencies. In general, this would have only been important for those people using packages that depend on `react` and were using npm@2...npm@3 would automatically de-dupe. However, when #5812 gets merged, dependencies will be scoped to react-native (on both npm@2 & npm@3), thus breaking projects that are using a package like `react-redux` for example, which depends on `react`. There would be two copies of React installed, and due to the use of haste modules in `react`, this would break the packager and cause naming collisions. This PR does three things - 1. Moves the dependency from dependencies to peerDependencies 2. Updates the local-cli to run `npm install react --save` when a new project is initialized. 3. Updates `react-native upgrade` to warn if `react` is not listed in the package.json's dependencies. **Note: This will require a shrinkwrap update.** Closes#5813 Reviewed By: svcscm Differential Revision: D2918380 Pulled By: androidtrunkagent fb-gh-sync-id: 6e4234a45284be2fdf6fedf29e70b2d2d0262486 shipit-source-id: 6e4234a45284be2fdf6fedf29e70b2d2d0262486
davidaurelio
commented
Feb 23, 2016
Good news. Almost everything is green now. This will be coming soon |
marcshilling
commented
Mar 1, 2016
So this didn't make it into 0.21? |
bestander
commented
Mar 1, 2016
Yeah, that is a can of worms. On Tuesday, 1 March 2016, Marc Shilling notifications@github.com wrote:
|
chirag04
commented
Mar 1, 2016
Using this in our fork and makes working with relay flawless. hope it gets merged soon. |
davidaurelio
commented
Mar 2, 2016
I’m through with all internal failures. CI is running right now, and I’m waiting for review. It’s coming. |
Summary:Follow-up to react/react-native#5084 This… - changes all requires within RN to `require('fbjs/lib/…')` - updates `.flowconfig` - updates `packager/blacklist.js` - adapts tests - removes things from `Libraries/vendor/{core,emitter}` that are also in fbjs - removes knowledge of `fbjs` from the packager Closesreact/react-native#5084 public Reviewed By: bestander Differential Revision: D2926835 fb-gh-sync-id: 2095e22b2f38e032599d1f2601722b3560e8b6e9 shipit-source-id: 2095e22b2f38e032599d1f2601722b3560e8b6e9
ide
commented
Mar 3, 2016
@skevy@davidaurelio you guys are heroes! thanks :D (& fingers crossed we can land this in 0.22) |
Kureev
commented
Mar 3, 2016
thanks, guys ❤️ |
chirag04
commented
Mar 3, 2016
You guys are amazing. Thanks for all the work 👍 |
Summary:Follow-up to react/react-native#5084 This… - changes all requires within RN to `require('fbjs/lib/…')` - updates `.flowconfig` - updates `packager/blacklist.js` - adapts tests - removes things from `Libraries/vendor/{core,emitter}` that are also in fbjs - removes knowledge of `fbjs` from the packager Closesreact/react-native#5084 public Reviewed By: bestander Differential Revision: D2926835 fb-gh-sync-id: 2095e22b2f38e032599d1f2601722b3560e8b6e9 shipit-source-id: 2095e22b2f38e032599d1f2601722b3560e8b6e9
Summary: As spicyj mentioned in commit 6a838a4, the ideal state of affairs when it comes to consuming `react` and `fbjs` from NPM is for the packager not to have knowledge of either package. This PR addresses the `fbjs` part of that, and relies on facebook/fbjs#95. **DO NOT MERGE** until #95 (or a variation) is in `fbjs` and is released to npm. This PR does several things: 1. Adds stub modules within RN that expose `fbjs` modules to be required using Haste. After discussing a few ideas with spicyj, this seemed like a good option to keep internal FB devs happy (and not make them change the way they write JS), but allow for removing packager complexity and fit in better with the NPM ecosystem. Note -- it skips stubbing `fetch`, `ExecutionEnvironment`, and `ErrorUtils`, due to the fact that these need to have Native specific implementations, and there's no reason for those implementations to exist in `fbjs`. 2. Removes the modules that were previously being used in lieu of their `fbjs` eq Closesreact/react-native#5084 Reviewed By: bestander Differential Revision: D2803288 Pulled By: davidaurelio fb-gh-sync-id: fd257958ee2f8696eebe9048c1e7628c168bf4a2 shipit-source-id: fd257958ee2f8696eebe9048c1e7628c168bf4a2
Summary: As spicyj mentioned in commit 6a838a4, the ideal state of affairs when it comes to consuming `react` and `fbjs` from NPM is for the packager not to have knowledge of either package. This PR addresses the `fbjs` part of that, and relies on facebook/fbjs#95. **DO NOT MERGE** until #95 (or a variation) is in `fbjs` and is released to npm. This PR does several things: 1. Adds stub modules within RN that expose `fbjs` modules to be required using Haste. After discussing a few ideas with spicyj, this seemed like a good option to keep internal FB devs happy (and not make them change the way they write JS), but allow for removing packager complexity and fit in better with the NPM ecosystem. Note -- it skips stubbing `fetch`, `ExecutionEnvironment`, and `ErrorUtils`, due to the fact that these need to have Native specific implementations, and there's no reason for those implementations to exist in `fbjs`. 2. Removes the modules that were previously being used in lieu of their `fbjs` eq Closesreact/react-native#5084 Reviewed By: bestander Differential Revision: D2803288 Pulled By: javache fb-gh-sync-id: 121ae811ce4cc30e6ea79246f85a1e4f65648ce1 shipit-source-id: 121ae811ce4cc30e6ea79246f85a1e4f65648ce1
Summary:Follow-up to react/react-native#5084 This… - changes all requires within RN to `require('fbjs/lib/…')` - updates `.flowconfig` - updates `packager/blacklist.js` - adapts tests - removes things from `Libraries/vendor/{core,emitter}` that are also in fbjs - removes knowledge of `fbjs` from the packager Closesreact/react-native#5084 Reviewed By: bestander Differential Revision: D2926835 fb-gh-sync-id: 2095e22b2f38e032599d1f2601722b3560e8b6e9 shipit-source-id: 2095e22b2f38e032599d1f2601722b3560e8b6e9
Summary:Follow-up to react/react-native#5084 This… - changes all requires within RN to `require('fbjs/lib/…')` - updates `.flowconfig` - updates `packager/blacklist.js` - adapts tests - removes things from `Libraries/vendor/{core,emitter}` that are also in fbjs - removes knowledge of `fbjs` from the packager Closesreact/react-native#5084 Reviewed By: bestander Differential Revision: D2926835 fb-gh-sync-id: 2095e22b2f38e032599d1f2601722b3560e8b6e9 shipit-source-id: 2095e22b2f38e032599d1f2601722b3560e8b6e9
Summary:Follow-up to react/react-native#5084 This… - changes all requires within RN to `require('fbjs/lib/…')` - updates `.flowconfig` - updates `packager/blacklist.js` - adapts tests - removes things from `Libraries/vendor/{core,emitter}` that are also in fbjs - removes knowledge of `fbjs` from the packager Closesreact/react-native#5084 Reviewed By: bestander Differential Revision: D2926835 fb-gh-sync-id: 2095e22b2f38e032599d1f2601722b3560e8b6e9 shipit-source-id: 2095e22b2f38e032599d1f2601722b3560e8b6e9
As @spicyj mentioned in commit 6a838a4, the ideal state of affairs when it comes to consuming
reactandfbjsfrom NPM is for the packager not to have knowledge of either package. This PR addresses thefbjspart of that, and relies on facebook/fbjs#95. DO NOT MERGE until #95 (or a variation) is infbjsand is released to npm.This PR does several things:
fbjsmodules to be required using Haste. After discussing a few ideas with @spicyj, this seemed like a good option to keep internal FB devs happy (and not make them change the way they write JS), but allow for removing packager complexity and fit in better with the NPM ecosystem. Note -- it skips stubbingfetch,ExecutionEnvironment, andErrorUtils, due to the fact that these need to have Native specific implementations, and there's no reason for those implementations to exist infbjs.fbjsequivalent modules, but didn't really need to be. These include:Map,isEmpty,crc32, andPromise.Promiseis a special case - it has been moved toPromise.native.jsinfbjs, so that a package such as Relay canrequire('fbjs/lib/Promise'), and not cause problems.fbjsmodules from the packager blacklist (yay!), and removesfbjsfrom the list of packages that the RN packager consumes Haste modules from. I left in thedownstreammodules, but I think those should really live within an FB-specific blacklist that you keep in your internal codebase. Let me know your thoughts there.fbjstounmockedModulePathPatternsfor Jest, to allow tests to not behave weirdly. This matches FB's internal Jest config.fetch,ExecutionEnvironment, andErrorUtilsfrom theflowconfigignore list.This, combined with facebook/fbjs#95 and a yet to be submitted Relay PR, allow for Relay to be used OOTB with React Native. Woo!
Looking forward to your comments :)
/cc @vjeux@spicyj
P.S. - The tests are going to fail here, until the
fbjsdep is updated.