React: Get rid of providesModule

Created on 24 Mar 2016  Â·  20Comments  Â·  Source: facebook/react

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.

Build Infrastructure

Most helpful comment

React.__SECRET_UTILS_DO_NOT_USE_OR_YOU_WILL_BE_FIRED_UNLESS_YOU_ARE_ENZYME_IN_WHICH_CASE_ITS_FINE.

All 20 comments

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).

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.

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.

In the context of the discussion occurring in https://github.com/facebook/react/issues/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.

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

React.__SECRET_UTILS_DO_NOT_USE_OR_YOU_WILL_BE_FIRED_UNLESS_YOU_ARE_ENZYME_IN_WHICH_CASE_ITS_FINE.

How is this migration going?

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.

Thanks for the response ! One question, could you please further explain what you mean by compiling to a "flat bundle"? How is that different to what you guys are doing now?

The idea is to always compile React into a single file, even on npm. We would use an optimized bundler that doesn't generate all the module registry code (like Rollup) so that the resulting bundle is smaller. It would also help solve some performance issues in the server environment where accessing process.env repeatedly is expensive.

We now compile React into flat bundles (#9327) so this is likely one of the next steps.

@gaearon Just to clarify, will this issue get rid of the haste system all together and use ES6 module syntax with relative paths?

@trueadm How soon will you get this done?

I'm looking forward to resolving this issue as I would like to explore/run this project with my fav IDE (Webstorm), which doesn't work with the current module system.

We'll probably switch to ES modules first, and then get rid of haste. In a few weeks hopefully.

Hi, its not clear to me here.. is @providesModule removed from React but still alive in React Native?

I don’t think it’s removed in React either.

thanks Dan - but we should understand that the overall direction is to get rid of haste and therefore @providesmodule from React/RN? I like the extreme convenience but do see it as a potentially confusing pattern. So am a little confused on whether I should advocate its use for learners of React/RN.

It shouldn't matter for learners: this is an internal convention. We are not advocating for others to use it. (And in fact, with changes in React 16, it will be impossible to require individual modules from React internals anyway.)

So this is removed in React with https://github.com/facebook/react/pull/11303/, right? Are we going to do the same thing with react native? Currently it's impossible to require things like StyleSheet from react-native for this exact reason, in my understanding

I don't know about React Native or about the problem you're describing. It might be better to ask in some RN community forum.

Was this page helpful?
0 / 5 - 0 ratings