Running Development Branches or Forked Versions react-native-firebase in Applications

[topherPedersen]

I was just wondering how I can go about testing out non-published versions of react-native-firebase in my organization's application?

A little background information: My work wants to start tracking downloads from paid marketing campaigns, so we want to use the new utmParameters feature of the dynamic-links module to do this in our app. However, this new feature doesn't seem to work on Android, so I think there might be a bug in react-native-firebase for Android which will need to be fixed in order to get this working.

My plan was to try and fork react-native-firebase and start working on a fix, but I wasn't able to get my fork to work. So my main question is: how would you guys go about tackling a problem like this? If you needed to test out (or even use) an unofficial build of react-native-firebase, how would you go about doing this?

If there's a standard or best way to go about doing this, please let me know and I can add it to the docs for future reference.

Any help would be appreciated, thanks!

P.S. I was able to get the monorepo by itself up and running, and could run tests, etc. I just couldn't get an alternative version up and running in a separate application.

[mikehardy]

Hey 👋 - yes, being a monorepo makes this kind of uncomfortable. I'm not aware of any really good developer experiences.

Here's what I've done personally:

1. I've just worked directly in node_modules using https://github.com/ds300/patch-package as my "version control" for the changes. This...actually works really well :-). In practice it is not gross at all, just a different way of thinking about how you're mashing the code around and what a patch or version control is. This is great for small items. (generate clean patches via npx patch-package @react-native-firebase/dynamic-links (or whatever) after you do cd android && ./gradlew clean)

2. I've worked directly with our e2e setup when I have larger items, and I've redefined the work from "make my end feature work" to "demonstrate failure in module via an e2e test, alter module code to make e2e test pass". This is also faster than it seems - the setup isn't bad and the tests are very fast to iterate on if you make a new test and mark it as it.only then use yarn tests:android:test-reuse to just pound on it https://github.com/invertase/react-native-firebase/blob/main/tests/README.md - then I use patch-package and our patch-generation CI job to take the "final" product from the PR and test integrate it in my work apps https://github.com/invertase/react-native-firebase/actions/workflows/create_test_patches.yml

3. I have never done this because it sounded no fun, and 1 and 2 above work well for me. But apparently you can use a scoped npmjs.com namespace and gitpkg then publish your fork and use your fork as a package.json dependency https://github.com/ramasilveyra/gitpkg

I implemented the patch-package generator specifically to address this issue and make the 1 + 2 cases somewhat comfortable. Hopefully something in here works for you?

Would love collaborate on a repair of anything if the UTM params aren't working. Obviously, they should work :-)

Cheers

[topherPedersen]

Thanks Mike! Appreciate the detailed response. I tried option number 3, going to try options 1 and 2 instead.