handling react-native updates?

[darthrellimnad]

Thanks for all of the work on this! After spending a lot of time struggling with Jest and the react-native docs (v 0.27.0) for setting up unit tests, I decided to give enzyme w/ mocha/chai a go and bam, I was up and running tests that matter to me.

I'm wondering what the process is like if/when react-native updates offer new functionality or breaking changes. Is there any coordination between you all and the react-native deployment process?

I expect the react-native docs for setting up tests for our app code will improve over time, but until then I'm happy to stick with these mocks and deal with additional app specific needs as they arise. I just want to know if there will be documentation or anything that will help us determine which versions of react-native-mock are stable/usable with corresponding versions of react-native. I guess the ideal situation is that part of the react-native deployment process includes the updated, matching, and battle-tested mocks :)

Thanks again, and sorry if any of this has already been discussed in other/old issues. I didn't see anything about it immediately aside from the note about more information soon in the readme.

[RealOrangeOne]

I try to update the dependancies as soon as react-native is updated. Regarding APIs. It's whenever enough PRs have been submitted that I deploy a release. Master can always be considered stable and working, however at this time there isnt a way you can install this through npm easily as it requires a build step.

[mroswald]

What about a postinstall scripts which Checks the existence of the build dir and executes npm run build if needed

[benjick]

Cool idea, but how would that work with devDeps?

[mroswald]

Yes, you're right. Installing devDeps before would be too much overhead. Will think about it 😀

[RealOrangeOne]

I think one of the best ideas would be to find a way to make travis deploy to npm under react-native-mock@next?

[darthrellimnad]

late to respond but thanks for the updates! so it sounds like this issue has to do with npm and devops on your end? i'm not super familiar with hosting through npm, but seems like you all are on top of react-native updates so i'm happy to get updates from npm when i see them.

only issue i can think of is if we ever need to freeze a react-native version, deal with older/legacy react-native code, or otherwise have to run tests that support old/deprecated react-native functionality... which likely won't be an issue for a while. maybe having tags in git we could reference would make that easier for the short term, but I suppose we could look at git history if we ever need to find a previous version of the mocks to work with older react-native code.

[RealOrangeOne]

Personally i'm not really too bothered with older versions of react-native, whilst they're still doing this highly active development process, it's fine for people to just lock the version, seeing as the versions are only specified for react in development. Once things settle down (and they come out of alpha?), then we'll work on more long-term releases, with better backwards compatability. For now, I think the best way to handle things will be with a react-native-mock@next release

[RealOrangeOne]

I have been looking into it, and it looks like we will be able to sort out a react-native-mock@unstable for bleeding-edge updates! Stay tuned!

[ZauberNerd]

@RealOrangeOne any updates on this? I'd really like to have up-to-date dependencies that don't put too much work for preparing releases onto you.

For that it would be great to have the release process completely automated - that way it also reduces the possibility of errors introduced by humans.

• It could be worth to take a look at: https://github.com/semantic-release/semantic-release
• or if that doesn't fit into this project we could create "nightly" releases on the CI that are going into a different npm dist-tag: https://docs.npmjs.com/cli/dist-tag
• or even just pushing the build output onto a different branch using subtrees: https://gist.github.com/cobyism/4730490 If that's something you'd be interested in, I could take a look at how to integrate these solutions into the travis-ci.

[RealOrangeOne]

I havent done any work on it, no. But I plan to implement a dist-tag that can be used, and autodeployed by a CI.