[React] Depend on npm "react" instead of shipping with a vendored copy

Question

[React] Depend on npm "react" instead of shipping with a vendored copy

ide opened this issue 9 years ago · 60 comments

Pretty certain this is on the radar but want to track it because it's going to make a real difference for the overall React ecosystem when RN can require libraries like react-static-container, react-relay, react-redux, etc... that depend on "react" but not "react-dom".

cc @vjeux @spicyj

skevy commented 9 years ago

👍

zsszatmari commented 9 years ago

+1 :)

sophiebits commented 9 years ago

No.

anaibol commented 9 years ago

+1

liusong1111 commented 9 years ago

+1

tlvenn commented 9 years ago

+1

barockok commented 9 years ago

+1

Answer 1 · 2015-09-23T22:10:38.000Z

Yeah, we're blocked on some fbjs stuff where we can't use the open-source copy of fbjs in RN right now because of some Flow conflicts (and maybe packager too?). @gabelevi was going to make a change to Flow that will allow us to move fbjs away from haste so that we can have more than one copy, not sure what the status of that is right now.

We probably won't get everything sorted out in time for React 0.14 but maybe we can do a point release after we fix things up.

cc @sebmarkbage

Answer 2 · 2015-09-24T00:48:45.000Z

Yes! This x 1000. Working on a react-router integration with RN right now and I had to dependency inject React into RR. Haha.

Interesting thing though, and something I didn't understand - "react-static-container" actually DOES work on RN. Is it because it requires React, not react, and the packager allows for that?

Answer 3 · 2015-09-24T17:10:06.000Z

Rest assured that we're aware and making this work was a major motivating factor for the packaging changes.

Answer 4 · 2015-10-16T00:03:57.000Z

Redux dropped support for React Native bindings (https://github.com/rackt/react-redux/releases/tag/v4.0.0), and there's also an open issue with Relay compatibility (though Relay has to change a few other things too). So as far as the state of the overall React ecosystem influences your roadmap you might want to give this a little bump in priority.

Answer 5 · 2015-10-16T03:32:23.000Z

It is my top priority after the blocker on fbjs/flow is done (which is unfortunately beyond me atm). cc @zpao

Answer 6 · 2015-10-16T04:28:30.000Z

We're still waiting on flow but as soon as that happens we'll get this sorted.

Answer 7 · 2015-10-16T04:36:46.000Z

Nice! Thanks for the update.

Answer 8 · 2015-10-16T14:43:26.000Z

cc @joesavona

Answer 9 · 2015-10-16T14:56:10.000Z

Thanks guys for being so diligent about this. I'm stoked to remove all my "-internal" private npm deps from my projects :)

Answer 10 · 2015-11-09T01:43:35.000Z

any update...

Answer 11 · 2015-11-09T02:33:21.000Z

Nope, still waiting on Flow but they should have their release out in the next week or so.

Answer 12 · 2015-11-15T08:52:07.000Z

Is there a fork/branch which already depends on react 14.0 that I can add to my package.json instead of the published package? I don't care about flow, but super excited to play with react-router and react-native.

Answer 13 · 2015-11-15T16:44:44.000Z

@abhishiv There is no feature branch. All latest features are almost always on master since it tracks FB's central codebase, which has only master and release cuts.

Answer 14 · 2015-11-24T04:35:32.000Z

Any ETA? :)

Answer 15 · 2015-11-24T04:45:10.000Z

Here is the Product Pains item for this issue: https://productpains.com/post/react-native/react-native-to-depend-on-react/

Answer 16 · 2015-11-24T19:57:37.000Z

A few folks above have alluded to workarounds. Could someone spell one out?

Answer 17 · 2015-12-02T10:18:13.000Z

Is this the Flow release you've been on about?

https://github.com/facebook/flow/releases/tag/v0.19.0

Answer 18 · 2015-12-02T19:15:42.000Z

Yes. Will take a little while for us to get all our ducks in order now but we should be unblocked.

Answer 19 · 2015-12-03T02:54:08.000Z

Great news!!! Willing to jump in and test as soon as things are closer to being ready.

Answer 20 · 2015-12-07T06:15:19.000Z

+1 That's great news. Looking forward to this.

Answer 21 · 2015-12-07T09:58:25.000Z

+1 looking forward to it!

Answer 22 · 2015-12-07T11:01:13.000Z

If you are interested in a workaround until this is real, here is how we've done it in gl-react (which is an universal lib across React and React Native) :

https://github.com/ProjectSeptemberInc/gl-react/releases/tag/v2.0.2#user-content-workaround

users can add a require("yourlib/react-native") or require("yourlib/react") once before all other imports to set the React instance in your lib. You lib must expose React. And when you want to make generic code, you use back YourLib.React.

( code react-runtime.js / react-native.js )

Answer 23 · 2015-12-07T18:56:43.000Z

Thanks @gre!

Answer 24 · 2015-12-14T17:20:38.000Z

+1 stoked to see this happen !!

Answer 25 · 2015-12-15T11:04:45.000Z

+1 ( as a ping :D )

Answer 26 · 2015-12-15T22:46:47.000Z

Commenting +1 doesn't help and is annoying. Locking this issue for now.

Answer 27 · 2015-12-15T23:58:55.000Z

If you all would like to show the team that you care about this issue, please up vote the issue on Product Pains.

https://productpains.com/post/react-native/react-native-to-depend-on-react/

Answer 28 · 2015-12-23T02:56:41.000Z

Update: Just sent off a diff internally for this. It will require us to release patch versions of fbjs and react before we can land so that everything actually works together, but hopefully we can pull everything together and land it in the next couple of weeks:

Thanks everyone for your patience.

Answer 29 · 2015-12-24T17:23:08.000Z

@spicyj woah holy crap. Awesome to see this! So stoked.

Answer 30 · 2015-12-30T20:00:03.000Z

This has landed in 6a838a4

I'm going to work later to verify that functionality is as expected when consuming something like Relay or Redux from npm (that depend on React).

Re: Relay, I'm 90% sure at this point that there are some bugs to fix (because there actually is still a tiny dependency on ReactDOM)...so it may not be 100% yet. But we're super close! Thanks for your work on this @spicyj!

Answer 31 · 2015-12-30T20:00:35.000Z

I broke the shrinkwrap. Wait for the next commit. :)

Answer 32 · 2015-12-30T20:32:54.000Z

satya164 commented 9 years ago

Answer 33 · 2015-12-30T23:56:30.000Z

@spicyj I saw your shrinkwrap change landed. Can you close this if you believe this issue has been resolved?

Answer 34 · 2015-12-30T23:57:12.000Z

Still waiting for one more then I will.

Answer 35 · 2015-12-31T03:22:52.000Z

Okay. There might be a small tail of issues, but the core of this has been done in 6a838a4 and a few followup commits on master and should be in react-native 0.18 when released. I haven't tested with Relay, etc., but if your app depends on react (needs to be the same version as RN uses, currently 0.14.5) and you ensure that RN does not have its own copy (i.e., that node_modules/react-native/node_modules/react does not exist) then things "should" now work.

Feel free to open new issues and tag me in them if there are problems and I'll try to take a look.

(unlocking this issue)

Answer 36 · 2015-12-31T06:22:54.000Z

@spicyj What does this mean for react native's usage with things like react-redux?

From the react-redux README:

React Native

Until React Native works on top of React instead of shipping a fork of React, you’ll need to keep using React Redux 3.x branch and documentation.

There isn't much explanation past there.

Answer 37 · 2015-12-31T20:19:40.000Z

@sunjay, it means that you will be able to use the latest react-redux NPM package instead of react-redux@3.x and anything that uses react@0.14.0 as a peerDependency.

Answer 38 · 2016-01-01T21:06:02.000Z

I was trying to get this to work on an app that both depends on react@0.14.5 and on react-native@master and I've got:

Error: Naming collision detected:
./node_modules/react/node_modules/fbjs/lib/warning.js
collides with
./node_modules/react-native/node_modules/fbjs/lib/warning.js

however I don't have any node_modules/react-native/node_modules/react

Answer 39 · 2016-01-01T21:14:28.000Z

@gre Try installing fbjs@0.6.0 at the top level and removing the inner ones? npm 3 would do this for you automatically, I believe.

Answer 40 · 2016-01-01T21:33:14.000Z

I also had to install react-transform-hmr in node_modules/react-native. I have no idea for what reason it wasn't resolved (maybe related to installing from facebook/react-native#master ).

Anyway, thanks it works now :)

Answer 41 · 2016-01-02T16:37:33.000Z

@gre the react-transform-hmr dep is just missing from master...that will be cleaned up before the next release.

Answer 42 · 2016-01-02T16:49:17.000Z

@skevy great! I have an unpublished version of gl-react-* libs that work fine with this new version and depending on react & react-native, this is so cool :)

Users will have to not forget about installing fbjs because it doesn't seem to dedup by default. I'm not sure the best way to avoid this, maybe it should be added as a peerDep (maybe not in react-native but at least on each lib that want to be "universal" ?)

Answer 43 · 2016-01-02T17:45:37.000Z

Sigh. I really wanted to only special-case the one copy of fbjs which is the one that RN uses, so any fbjs in a sibling directory would be okay to be bundled twice (since fbjs modules tend to not be stateful). Guess I'll need to change the packager more to make that work…

Answer 44 · 2016-01-07T18:28:07.000Z

@sunjay I managed to get it to work. You can take a look at the following repo
example-react-native-redux however there are some modification require in package modules which I described here reduxjs/react-redux#236 (comment)

Answer 45 · 2016-01-11T16:44:25.000Z

Any chance this will be fixed for 0.18?

Answer 46 · 2016-01-11T16:51:35.000Z

@cancan101 it will be fixed for 0.18. It is already fixed for 0.18-rc

Answer 47 · 2016-01-11T17:07:19.000Z

Sorry, I should clarify the 'this' i meant is the issue with fbjs and it did not seem to be fixed in the RC.

Answer 48 · 2016-01-12T17:27:17.000Z

I ran into the fbjs conflict issue using npm 2. @spicyj's solution of installing fbjs at the root level didn't seem to solve it, but nuking my entire node_modules directory, installing npm 3, and then reinstalling everything did.

The getting started docs should probably be updated to recommend npm 3 if that's the official solution, too bad that it's so slow!

Answer 49 · 2016-01-12T17:37:23.000Z

Use @alinz solution, it works ! ;)

Answer 50 · 2016-01-12T17:45:39.000Z

@Mokto yeah, but it involves some pretty nasty hacks to work with npm@2 (reaching into packages and deleting the fbjs dependencies).

Answer 51 · 2016-01-12T19:17:19.000Z

@corbt I agree that it involves some folder moving and hack but it should not cause you any problem. fbjs will be moved out from react-native eventually, in a meantime if you have a module that does not work with npm@3 then that would be your only options.

Answer 52 · 2016-01-12T20:29:12.000Z

I know it is nasty but you could add this to you package.json :

"postinstall": "npm run setup_project"

Answer 53 · 2016-01-12T20:45:10.000Z

Also we need to detect in setup_project whether user is using npm@2 or npm@3

On Jan 12, 2016, at 3:30 PM, Mokto notifications@github.com wrote:

I know it is nasty but you could add this to you package.json :

"postinstall": "npm run setup_project"

—
Reply to this email directly or view it on GitHub.