Open darthrellimnad opened 8 years ago
RealOrangeOne
commented
8 years ago 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
commented
8 years ago What about a postinstall scripts which Checks the existence of the build dir and executes npm run build if needed
benjick
commented
8 years ago Cool idea, but how would that work with devDeps?
mroswald
commented
8 years ago Yes, you're right. Installing devDeps before would be too much overhead. Will think about it 😀
RealOrangeOne
commented
8 years ago 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
commented
8 years ago 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
commented
8 years ago 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
commented
8 years ago 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
commented
7 years ago @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.
RealOrangeOne
commented
7 years ago 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.
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.