Move getNextDebugID() to React package.

[wacii]

See #8487

When multiple renderers are used in development, react issues a warning from ReactComponentTreeHook.

Why?

Items are stored in ReactComponentTreeHook's itemMap for debug info during development. The keys for these entries are generated by the following code.

var nextDebugID = 1;

function getNextDebugID() {
  return nextDebugID++;
}

The problem is both ReactDOM and ReactDOMServer have a copy of this, and so will generate the same series of numbers, overwriting the debug entries generated by the other.

Now it lives only in React.

[gaearon]

Thanks! I added this to list of changes we want to push out in 15.5.
Do you think you could rebase this on master?

[sebmarkbage]

Don't like. Another stateful module in isomorphic wish we tried hard to get away from (e.g. current owner). :(

[gaearon]

It should die with the tree hook, I think?

[wacii]

The code is now up to date.

[gaearon]

What is this file? Looks like a build product that shouldn't be checked in.

[wacii]

See #9078.

It does look that way. But shared modules are now accessed under their package name, so require('react/lib/getNextDebugID') instead of require('getNextDebugID'). Why this was done with an extra module, what @sebmarkbage referred to as forwarding modules I believe, and not an alias...I have no idea.

[sebmarkbage]

Yea. This is correct. When we switch to lerna or yarn workspaces, this will be generated by tooling but since we don't have the tooling in place yet, I just checked in forwarding modules.

[sebmarkbage]

Forwarding modules is so much better than config aliases because it covers all tooling at once. E.g. webpack aliases are the worst because you have to replicate it in node, jest, flow, and anything else that need the module graph.

[gaearon]

Aah. Thanks for explaining.

[gaearon]

(That's the same reason we don't allow absolute imports via Webpack config in CRA 😄 )

[acdlite]

I cherry-picked this onto our release branch. It will go out in 15.5. Thanks!