Get rid of providesModule

[zpao]

It's been great for us at FB but not so much for everybody else. It's long been a goal to get rid of this and just use common js / es6 modules but haven't put the time in yet.

This change will require changes internally at FB and probably some work with fbjs so I'm going to assign this to myself.

[aweary]

Would this remove all the providesModule comments from the header comment in each file? I've found it really helpful when searching for a component in the repo (since there are no relative import paths).

[gaearon]

I've found it really helpful when searching for a component in the repo (since there are no relative import paths).

If we remove providesModule we’ll use relative paths like everybody else does.

[iamdustan]

I’m curious if the “not so great for everyone else” bit is primarily a documentation/marketing issue? It’s business-as-usual for FB, but totally foreign and not referenced anywhere when someone comes looking at the code in here.

As a casual observation, Haste hasn’t seemed to have hindered outside contributors or their contributions to the RN project.

[aweary]

In the context of the discussion occurring in #6460, I want to start discussing how this might affect community tools that may rely on React internals. At enzyme we do import from the lib folder so we have a vested interest in how this might affect our ability to integrate.

[zpao]

Unknown until we do it. Ideally we would expose everything that a library like Enzyme would need. This impacts our addons-* packages as well.

[gaearon]

React.__SECRET_UTILS_DO_NOT_USE_OR_YOU_WILL_BE_FIRED_UNLESS_YOU_ARE_ENZYME_IN_WHICH_CASE_ITS_FINE.

[acpower7]

How is this migration going?

[gaearon]

Nothing happening right now but I'm pretty sure we'll be looking at it this year since we want to compile React away to a flat bundle, and in this case Haste is not as useful to us. Moving the files easily is still nice so I'm not sure which approach we would take.