Split React and ReactDOM from npm build.

[iamdustan]

See #5974.

This solves the first two parts of #5974.

The “common” consumption method from npm should have a fully separated renderer with this. @providesModule I think would also continue operating as expected. The only deferred work is separating the browser builds.

I’m not sure what the demand for the stand-alone browserified builds is, but that is definitely much more work with the build tooling. Personally, I’d be happy to see this be the next step in the separation of the two. It’s lower risk as it only modifies two of the three worlds (npm and haste). It trades the React.native.js file for a ReactBrowser.js file which sounds like a decent tradeoff to me.

This isn’t quite there yet...I have to work through the grunt tasks to ensure the browser builds still work...

[zpao]

This won't work out of the box in our primary @providesModule world. We could make it but it's trickier and more prone to breakage.

[iamdustan]

How can I test that? Or is the fact that grunt build:basix fails indicative of it being incorrect?

[zpao]

You can't, unless you want to come work at FB :) Introducing a normal node require into @providesModule code requires more work and doing things in a different part of the codebase that just means we have a little bit more to keep in mind when we sync.

[iamdustan]

Remotefriendlycoughcough

Would abusing the RN packager be analogous to haste tooling? I dug around a bit today and noticed this current impl is a bit lacking.

[zpao]

This is just a matter of having to do special configs for these things in our website code to work. Nothing else to do about it.

In this code base you should be able to make it work - we have to hard code that react-current-owner is normal and should not get rewritten. And you have to do that in the gulpfile (again, sorry for the crazy build system). https://github.com/facebook/react/blob/master/gulpfile.js#L42 - we should make that Object.assign({}, require('fbjs/module-map'), {'react-current-owner': 'react-current-owner'}). Basically the build assumes that if something isn't on the whitelist, then it must be a providesModule module. We dump all our modules into lib/ and rewrite the requires so they are relative. So this is currently getting rewritten to require('./react-current-owner') which is going to fail when browserifying.

[iamdustan]

wasn’t there some work to reign in the build system somewhere?

Updated with that and now grunt build works correctly, the browser examples each work, and I can npm link this into my custom renderer and require react directly instead of react/lib/ReactIsomorphic.

[zpao]

This seems like a pretty reasonable first step, will just need to make sure we do the @providesModule bit right. Part of me wonders if this is quite worth it yet. Ideally we get to a place where we don't use @providesModule in React and then this fits in really naturally.

[facebook-github-bot]

@iamdustan updated the pull request.

[iamdustan]

Ideally we get to a place where we don't use @providesModule in React and then this fits in really naturally.

is there a timeline or active work regarding this?

Tbh, my motivation for this separation is for React Hardware which is already dancing with internals enough as it is :)

[facebook-github-bot]

@iamdustan updated the pull request.

[iamdustan]

Testing this locally, I bumped to alpha.2 and did a local npm install which worked as expected on React Hardware. Additionally the browser builds all worked as expected.

Is there anything I can do regarding haste?

This PR was able to remove one of two *.native.js shim files added in c29642d

According to reduxjs/react-redux#292 (comment) it sounds like the Relay dependency on the second file is handled, so only the ReactTestUtils needs to be accounted for yet to remove the second shim. Whilst that may be a bit outside the scope of this PR since it involves RN as well, I’d be happy to take a look into this.

[zpao]

I'm inclined to say that we aren't going to get to this this week and it'll miss v15 :( I think there are just a few too many unknowns with npm and how the 3rd package should be depended on and shared (eg, I would expect with npm2 that react and react-dom each install their own react-current-owner, which would not be what we want). I think requiring that react-current-owner becomes installed by apps would really awkward.

[iamdustan]

Based on my understanding, it would be more expedient and less invasive to the React codebase to deprecate and eventually remove the CurrentOwner concept than attempt to continue finding a way to create another package for React consumers to depend on. Especially given npm@2 and npm@3’s differing trees I could see this become a source of confusion in the future.

If that is an accurate assessment of the direction React is heading I would vote for closing this and the original issue (#5974) in favor of the CurrentOwner cleanup. #6331 already solves the npm side of #5974 won, and if CurrentOwner didn’t exist I don’t think there is anything else that would be impeding #5974 from being complete.

[gaearon]

Based on my understanding, it would be more expedient and less invasive to the React codebase to deprecate and eventually remove the CurrentOwner concept than attempt to continue finding a way to create another package for React consumers to depend on.

Agreed. I’m closing for this reason. Thanks for checking the viability of this!