Incorrect dependency version for React needed for React Native 0.43

[nicinabox]

React Native 0.43 has a peer dependency on React 16.0.0-alpha.6, but react-compat doesn't check for major versions greater than 15.

This has the lovely effect of having the app compile and run successfully, but all the tests fail because it enzyme resolves to react@0.13-14.

It looks like this should be fairly straightforward. I could probably draft a PR tomorrow if need be.

Here's the full error:

react-addons-test-utils is an implicit dependency in order to support react@0.13-14. Please add the appropriate version to your devDepen
dencies. See https://github.com/airbnb/enzyme#installation
/Users/haynesn/code/CrimsonConnect/node_modules/enzyme/build/react-compat.js:143
      throw e;
      ^

Error: Cannot find module 'react-addons-test-utils'
    at Function.Module._resolveFilename (module.js:470:15)
    at Function.Module._load (module.js:418:25)
    at Module.require (module.js:498:17)
    at require (internal/module.js:20:19)
    at /Users/haynesn/code/CrimsonConnect/node_modules/enzyme/build/react-compat.js:133:21
    at Object.<anonymous> (/Users/haynesn/code/CrimsonConnect/node_modules/enzyme/build/react-compat.js:219:5)

[snip]

[ljharb]

There are no react versions greater than 15, yet.

[nicinabox]

@ljharb Care to elaborate?

• React 16.0.0-alpha.6 peer dependency in React Native 0.43
• React-native 0.43 depends on React 16.0.0-alpha.6
• React 16.0.0-alpha.3 tag

[ljharb]

Alphas aren't releases; enzyme doesn't tend to support React alphas.

Since React 16 is only in alpha, React Native shouldn't be requiring it in a non-alpha release.

[nicinabox]

That may be true, but that's not how they manage compatibility between React and React Native. Depending on the alpha is intentional.

Still, it doesn't change that enzyme incorrectly identifies react major versions > 15 as 0.13-0.14.

[ljharb]

I agree that the error message is unhelpful; the best we could do to improve it is determine that you're using React > 15, and throw immediately.

[benjamingr]

Any ETA on supporting react 16? It would help us make sure MobX supports React 16 when it is released :)

[borisyankov]

It has been a month and a half since Enzyme has become incompatible with the latest stable React Native releases.
It is one thing to say that @nicinabox is installing some random alpha version. He hasn't. He is using RN 0.43 or the latest 0.44

The final React 16.0.0 is several months ahead (at least).
If you are OK with not making a change to Enzyme till then, at least add a note that 'currently Enzyme is not compatible with React Native' to the documentation.

[ljharb]

This is a bug with react-native. An alpha should not be depended upon; and if it's stable enough to depend upon, it shouldn't be an alpha.

Please feel free to file a bug on react-native and/or react.

[gaearon]

I apologize for this. I know it is frustrating, but unfortunately React 16 is a big change (basically a rewrite), and there’s a chicken and egg problem here.

React Native is tightly coupled to React, but unlike React DOM, has a much faster breaking change release cycle (a month rather than a year). As a result, while we’re able to batch all ReactDOM breaking changes in yearly releases, we can’t really do the same for React Native.

We have to dogfood 16 in order to fix issues in it, and we can’t let the open source version of RN diverge from an internal version because there’s so much more surface area, and a separate open source version would immediately go stale.

For this reason, RN uses an “alpha” version of the react package. It’s not really “alpha” in the sense of being unstable (we’re using it in production), but it does mean third party libraries are not guaranteed to be compatible with it, and it contains breaking changes compared to previous versions.

Whether or not Enzyme is willing to support react@16 alphas is up to Enzyme’s maintainers, but an official stable release of 16 depends on many completely unrelated prerequisites (e.g. server rendering support) which means it will take a few more months even though RN already uses it.

The matter is also complicated by the fact that react@16 is not the reconciler rewrite. It is just a package with React.Component and React.createElement(). The reconciler rewrite will be shipped to RN later (and we’ll flip the flag to enable it when we use it more in production). So there will be further changes to how React 16 works in RN.

[ljharb]

I guess I'd expect an RN that depends on a react alpha to be an alpha itself - npm maintains 2 versions at once (4, and 5 alpha), for example, so I don't see why RN couldn't do the same.

Server rendering is a pretty important use case for enzyme - render, for example - so that seems like it might be a blocker for v16 support, even if we choose to support it in alpha.

[gaearon]

I guess I'd expect an RN that depends on a react alpha to be an alpha itself - npm maintains 2 versions at once (4, and 5 alpha), for example, so I don't see why RN couldn't do the same.

My impression is it just would not very practical, as it would effectively make all future releases of RN “alphas” for a few months even though they’re more stable than previous versions. React itself is such a tiny part of React Native (especially the react` package itself) that its version doesn’t reflect stability of RN itself. I understand this has ramifications for the community though.

Perhaps this is something you could discuss with @yungsters.

[andriichernenko]

Doesn't seem like this issue is going to be resolved anytime soon.
What do we do in the meantime? I am working on a new project which uses RN 0.44, so I don't have any existing code which relies on enzyme. Should I downgrade to RN 0.42.3 or try to find some alternatives to enzyme (not even sure there are any)?

[aschrijver]

Issue is still there with latest and greatest RN releases :(
With #893 (comment) and enzyme not supporting alpha's we could be stuck for many months more.
Like @andriichernenko .. any advice?

[notabeatle]

I entirely agree with pushing back against FB/React/RN's confusing abuse of the "alpha" label—3rd party lib/tool support for RN in general is shockingly chaotic, and I think this cavalier attitude to release labeling and discipline is no small part of it—however they've shown no signs of changing their bizarre behavior, so it appears that any lib/tool that wishes to support RN ought to accept it or drop that support (publicly and as loudly as possible if you do, please). This ongoing clash of pushing-insane-release-labeling versus firmly-insisting-on-sane-release-labeling is just making life difficult for developers (users) of RN and related projects.

In short, Facebook's entirely at fault for labeling their releases in a way that breaks convention, harms communication, erodes confidence/trust, and is generally and obviously poor practice for a bunch of good reasons, but having so many of the tools/libs that "support" RN always be several versions behind (and not always the same number of versions behind) RN stable really sucks for those of us trying to use it, regardless of whose fault it is.

[gaearon]

I think calling it "abuse" is a bit too much given that React team literally spends months of effort on things that don't matter to Facebook but are significant to the open source community.

Yes, this particular case is unfortunate, and I'm open to suggestions on how we can make this better. What would you suggest we do instead?

[notabeatle]

It's not a bit too much to call the use of alpha to signify production-ready code which may be depended upon by non-alpha software abuse of the term alpha. That's exactly what it is. It's misleading to such a degree that it makes taking any meaning at all from their use of the term dangerous. It would be difficult to abuse a word more strongly than that. You may be reading something into my comment that's not there—I nowhere accused them of abusing humans, only language, which they are doing in such a way that it is clearly harming communication and collaboration, which are often primary aims of the use of language. The strength of the term I chose for what they've done to the utility of the term alpha in the context of the project is appropriate, as it's clearly being grossly misused.

[EDIT] As for suggestions, my preference would be that tools that support RN consider any dependencies that RN calls stable to be stable regardless of the stability-signifying labels those dependencies have chosen for themselves, or else prominently and persistently announce refusal to support RN releases with apparently-unstable dependencies, so that hopefully authors of things like e.g. Microsoft/Typescript's getting started with RN guide will catch on and include disclaimers about this weirdness alongside recommendations of tools like Enzyme, and maybe React/RN will change either their stability-signifying conventions or dependency inclusion behaviors so that they make more sense.

[ljharb]

The React team does amazing things, and I'm very glad Facebook and the React team are doing them - but that very statement, I think, represents the problem: that things being significant to the open source community don't automatically make them matter to Facebook as a whole.

---

In this situation, I think the only path for now is to wait on #1007; after which, I hope both the React and React Native teams will ensure that any release includes an enzyme adapter that is compatible with it. I think that any other tooling that has issues will probably need to develop their own adapter pattern.

[ljharb]

I don't think this is relevant any more now that we're on v3 - a React Native enzyme adapter should address these issues.