Depend to react-native as a peer

[jevakallio]

I'm proposing two changes to how react-native dependencies should be handled:

Consider react-native a peer dependency.

This library is a plugin, it does not make use of React native, it adds functionality to it. As such there will never be a project that uses react-native-router, but does not already import React native.

Defining react-native as a dependency can cause issues when the relaxed semver requirement allows different versions of the framework do be installed by different plugins, and the dependent project itself. This just broke my build when upgrading to react-native 0.6.0, and prevented me from using 0.6.0-rc without forking react-native-router. See: facebook/react-native#1606 (comment)

Consider react-native to be always forwards compatible.

Facebook has now moved to a two week release cycle, where they release a new minor version every two weeks and simultaneously release a release candidate of the next minor version.

While there may be breaking changes in the future, arbitrarily preventing users of react-native-router to upgrade is a bigger limitation.

[yesmeck]

👍

[helielson]

+1

[leejms]

+2

[jevakallio]

I updated the pull request to consider all release candidates as valid versions, because even with the peerDependencies modification the -rc postfix in the version number causes semver incompatibility.

@t4t5 if you'd be so kind, would you consider this pull request? Having to keep a personal fork up to date every two weeks in order to use this component is getting a bit cumbersome :)

[jevakallio]

Reverted the release candidate change, apparently in reality npm version checking does not work identically with the semver checker I used.

Can't think of a great way to allowing the release candidates, but the above still stands for the stable versions.