kylefang/react-native-firebase
1
0
Fork 0
mirror of https://github.com/zhigang1992/react-native-firebase.git synced 2026-04-25 04:54:51 +08:00
Code Issues Packages Projects Releases Wiki Activity

tests: fix coverage config (#3541)

Browse Source 
[skip-ci]
This commit is contained in:
Mike Diarmid
2020-04-24 20:17:32 +01:00
committed by GitHub
parent f58700e686
commit c1197a4666
7 changed files with 140 additions and 109 deletions
Download Patch File Download Diff File Expand all files Collapse all files

70
.github/PULL_REQUEST_TEMPLATE.md vendored
View File

@@ -1,58 +1,40 @@
### Description
<!-- Thanks for submitting a pull request! Please provide enough information so that others can review your pull request properly. -->
<!-- If this PR fixes an issue, type "Fixes #issueNumber" to automatically close the issue when the PR is merged. -->
### Summary
<!-- Explain the **motivation** for making this change e.g. what existing problem does the pull request solve? -->
### Related issues
<!-- If this PR fixes an issue, include "Fixes #issueNumber" to automatically close the issue when the PR is merged. -->
### Release Summary
<!-- An optional description that you want to appear on the generated changelog -->
### Checklist
- [ ] Supports `Android`
- [ ] Supports `iOS`
- [ ] `e2e` tests added or updated in packages/\*\*/e2e
- [ ] Flow types updated
- [ ] Typescript types updated
- I read the [Contributor Guide](/CONTRIBUTING.md) and followed the process outlined there for submitting PRs.
- [ ] Yes
- My change supports the following platforms;
- [ ] `Android`
- [ ] `iOS`
- My change includes tests;
- [ ] `e2e` tests added or updated in `packages/\*\*/e2e`
- [ ] `jest` tests added or updated in `packages/\*\*/__tests__`
- [ ] I have updated TypeScript types that are affected by my change.
- This is a breaking change;
- [ ] Yes
- [ ] No
### Test Plan
<!-- Demonstrate the code is solid. -->
<!-- Example: The exact testing commands you ran and their final output (e.g. screenshot of test summary). -->
<!-- Example: Screenshots / videos if the pull request changes UI related code such as Notifications or Admob -->
### Release Plan
<!-- Help reviewers and the release process by writing your own release notes. See below for examples. -->
[CATEGORY][type] [LOCATION] - Message
<!--
**INTERNAL tagged notes will not be included in the next version's release notes.**
CATEGORY
[----------] TYPE
[ TYPES ] [-------------] LOCATION
[ JS ] [ BREAKING ] [------------------]
[ GENERAL ] [ BUGFIX ] [ {FirebaseModule} ]
[ INTERNAL ] [ ENHANCEMENT ] [ {Filename} ]
[ IOS ] [ FEATURE ] [ {Directory} ] |-----------|
[ ANDROID ] [ MINOR ] [ {Framework} ] - | {Message} |
[----------] [-------------] [------------------] |-----------|
EXAMPLES:
[IOS] [ANDROID] [BREAKING] [AUTHENTICATION] - Change a thing that breaks other things
[ANDROID] [BUGFIX] [FIRESTORE] - Did a thing to fix a thing with a Firestore thing
[JS] [BREAKING] - Remove a deprecated thing
[TYPES] [ENHANCEMENT] [NOTIFICATIONS] - Update flow types for a thing in notifications
[JS] [ENHANCEMENT] - Expose export of a internal thing utility for public usage
[INTERNAL] [FEATURE] [./utils] - Added an internal util to make doing a thing easier
-->
<!-- Demonstrate the code you've added is solid, e.g. test logs or screenshots. -->
---
Think `react-native-firebase` is great? Please consider supporting the project with any of the below:
- 👉 Donate via [Open Collective](https://opencollective.com/react-native-firebase/donate)
- 👉 Follow [`React Native Firebase`](https://twitter.com/rnfirebase) and [`Invertase`](https://twitter.com/invertaseio) on Twitter
- 👉 Star this repo on GitHub ⭐️
- 👉 Contribute; see our [contributing guide](/CONTRIBUTING.md)
- 👉 Follow [`React Native Firebase`](https://twitter.com/rnfirebase) and [`Invertase`](https://twitter.com/invertaseio) on Twitter

5
.github/workflows/linting.yml vendored
View File

@@ -4,10 +4,14 @@ on:
pull_request:
branches:
- '**'
push:
branches:
- master
jobs:
linting:
name: ESLint
timeout-minutes: 5
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v1
@@ -50,6 +54,7 @@ jobs:
typescript:
name: TypeScript Build Validation
runs-on: ubuntu-latest
timeout-minutes: 5
steps:
- uses: actions/checkout@v1
with:

3
.github/workflows/tests_e2e.yml vendored
View File

@@ -4,6 +4,7 @@ on:
pull_request:
branches:
- '**'
jobs:
# ------------------
# Android
@@ -12,6 +13,8 @@ jobs:
name: Android
runs-on: macos-latest
timeout-minutes: 30
env:
CODECOV_TOKEN: ${{ secrets.CODECOV_TOKEN }}
steps:
- uses: actions/checkout@v1
with:

10
.github/workflows/tests_jest.yml vendored
View File

@@ -4,11 +4,17 @@ on:
pull_request:
branches:
- '**'
push:
branches:
- master
jobs:
jest:
name: Jest
timeout-minutes: 5
runs-on: ubuntu-latest
env:
CODECOV_TOKEN: ${{ secrets.CODECOV_TOKEN }}
steps:
- uses: actions/checkout@v1
with:
@@ -31,3 +37,7 @@ jobs:
run: yarn --no-audit --prefer-offline
- name: Jest
run: yarn run tests:jest-coverage
- name: Submit Coverage
run: |
./node_modules/.bin/codecov
shell: bash

1
.gitignore vendored
View File

@@ -557,3 +557,4 @@ app.playground.js
app.admob.js
app.smartreply.js
eslint-report.json
yarn.lock

157
CONTRIBUTING.md
View File

@@ -5,8 +5,8 @@ First, thank you for considering contributing to React Native Firebase! It's peo
We welcome any type of contribution, not just code. You can help with;
- **QA**: file bug reports, the more details you can give the better (e.g. platform versions, screenshots SDK versions & logs)
- **Docs**: improve reference coverage, add more examples, fix typos or anything else you can spot. At the top of every page on our docs site you can click the `Edit` pencil to go to that pages markdown file, or view the [documents](https://github.com/invertase/react-native-firebase/tree/master/docs) directly
- **Marketing**: writing blog posts, howto's, ...
- **Docs**: improve reference coverage, add more examples, fix typos or anything else you can spot.
- At the top of every page on our docs site you can click the `Edit Page` button to go to that pages markdown file or TypeScript definition file, or view the [documents](https://github.com/invertase/react-native-firebase/tree/master/docs) directly
- **Community**: presenting the project at meetups, organizing a dedicated meetup for the local community, ...
- **Code**: take a look at the [open issues](issues). Even if you can't write code, commenting on them, showing that you care about a given issue matters.
- **Donations**: we welcome financial contributions in full transparency on our [open collective](https://opencollective.com/react-native-firebase).
@@ -15,35 +15,13 @@ We welcome any type of contribution, not just code. You can help with;
## Project Guidelines
As the creators and maintainers of this project, we want to ensure that the project lives and continues to grow. Not blocked by any singular person's time.
One of the simplest ways of doing this is by encouraging a larger set of shallow contributors. Through this we hope to mitigate the problems of a project that needs updates but there is no-one who has the power to do so.
### Ownership
If you get a merged Pull Request, regardless of content (typos, code, doc fixes), then you'll most likely receive push access to this repository. This is checked for on pull request merges and an invite is sent to you via GitHub.
Offhand, it is easy to imagine that this would make code quality suffer, but in reality it offers fresh perspectives to the codebase and encourages ownership from people who are depending on the project. If you are building a project that relies on this codebase, then you probably have the skills to improve it and offer valuable feedback.
Everyone comes in with their own perspective on what a project could/should look like, and encouraging discussion can help expose good ideas sooner.
### Why do we give out push access?
It can be overwhelming to be offered the chance to wipe the source code for a project.
Do not worry, we do not let you push directly to master or any of the version (e.g. v4.x.x) branches, these branches are protected by the review process. We have the convention that someone other than the submitter should merge non-trivial pull requests.
As an organization contributor, you can merge other people's pull requests, or other contributors can merge yours. You will not be assigned a pull request, but you are welcome to jump in and take a code review on topics that interest you - just let others know you're picking up something by tagging in on an existing issue or creating a new one and assigning it to yourself.
This project is **not** continuously deployed, this leaves space for debate after review and offering everyone the chance to revert, or make an amending pull request. If it feels right and follows the guidelines, then merge.
### How can we help you get comfortable contributing?
It is normal for a first pull request to be a potential fix for a problem but moving on from there to helping the project's direction can be difficult.
We try to help contributors cross that barrier by offering good first step issues (labeled `good-first-issue`). These issues can be fixed without feeling like you are stepping on toes. Ideally, these are non-critical issues that are well defined. They will be purposely avoided by mature contributors to the project, to make space for others.
Additionally issues labeled `needs-triage` or `help-wanted` can also be picked up, these may not necessarily require code changes but rather help with debugging and finding the cause of the issue whether it's a bug or a users incorrect setup of the library or project.
Additionally issues labeled with the `Help:` prefix can also be picked up, these may not necessarily require code changes but rather help with debugging and finding the cause of the issue whether it's a bug or a users incorrect setup of the library or project.
We aim to keep all project discussion inside GitHub issues. This is to make sure valuable discussion is accessible via search. If you have questions about how to use the library, or how the project is running - GitHub issues are the go-to tool for this project.
@@ -52,7 +30,7 @@ We aim to keep all project discussion inside GitHub issues. This is to make sure
This is normal don't worry - not everyone can develop native code for Obj-C and Java, we understand that.
Although we won't merge Pull Requests unless they support all applicable platforms, we do however recommend that you still submit a PR
for the Platform that you do know and then label it as either `ios-help-wanted` or `android-help-wanted` (or post a comment requesting it to be labeled).
for the Platform that you do know and then label it as either `Help: iOS` or `Help: Android` (or post a comment requesting it to be labeled).
This will allow other contributors to help add the missing platform support by making changes to your existing PR.
### Our expectations on you as a contributor
@@ -63,19 +41,11 @@ To quote [@alloy](https://github.com/alloy) from [this issue](https://github.com
We want contributors to provide ideas, keep the ship shipping and to take some of the load from others. It is non-obligatory; we’re here to get things done in an enjoyable way. :trophy:
The fact that you will have push access will allow you to:
- Avoid having to fork the project if you want to submit other pull requests as you will be able to create branches directly on the project.
- Help triage issues and merge pull requests.
- Pick up the project if other maintainers move their focus elsewhere.
It is up to you to use those superpowers or not though 😉
We ask though that you follow the conduct guidelines set out in our [Code of Conduct](/CODE_OF_CONDUCT.md) throughout your contribution journey.
We do ask though that you follow the conduct guidelines set out in our [Code of Conduct](/CODE_OF_CONDUCT.md) throughout your contribution journey.
### What about if you have problems that cannot be discussed in a public issue?
You can reach out to us directly via Discord direct messages or Twitter if you'd like to discuss something privately, alternatively you can also email us at oss@invertase.io
You can reach out to us directly via Discord direct messages or Twitter if you'd like to discuss something privately, alternatively you can also email us at `oss[at]invertase.io`
#### Project Owners
@@ -83,7 +53,6 @@ You can reach out to us directly via Discord direct messages or Twitter if you'd
- Twitter: [@mikediarmid](https://twitter.com/mikediarmid)
- Discord: `Salakar#1337`
- [Ehesp](https://github.com/Ehesp)
- Twitter: [@elliothesp](https://twitter.com/elliothesp)
- Discord: `Alias#3980`
@@ -97,24 +66,68 @@ Working on your first Pull Request? You can learn how from this _free_ series, [
### Implementation Guidelines
- Ensure any new JS implementations match the official Firebase JS SDK implementation
- This includes matching up with the same method names, types, usages, inputs and outputs
- In some instances this is not always possible e.g. a Firebase Module that does not exist in the Web SDK, such as `crashlytics()` or the implementation can't work (or not performant) in the React Native environment, such as `storage().putString()`
- Methods/Features that are specific to a single platform only should be namespaced as such in your implementation
- For example when implementing an iOS **only** method:
- [❌] `firebase.crashlytics().someNewMethodForIos()`
- [✅] `firebase.crashlytics().ios.someNewMethod()`
- If a method works on both platforms then there's no need to namespace it
- Ensure any new JS implementations mirror the official Firebase JS SDK implementation.
- This includes matching up with the same method names, types, usages, inputs and outputs.
- In some instances this is not always possible.
- Methods/Features that are specific to a single platform only should be documented as such and the types description `@platform` annotated;
```ts
export SomeInterface {
/**
* A cool method.
*
* @platform ios iOS
*/
aCoolMethod(): Promize<null>;
}
```
- If a method works on both platforms then there's no need to annotate it
- Name your native code methods the same as the JS method name
- e.g. the Android (`@ReactMethod`) implementation of `firebase.auth().signInWithEmailAndPassword()` is named `signInWithEmailAndPassword`
### Testing Code
---
The project has a detox powered `e2e` testing app located in `/tests`. See it's local testing guide [here](https://github.com/invertase/react-native-firebase/blob/master/tests/README.md).
## Local Setup
### Submitting code for review
To get started locally the following steps are required:
Any code changes that are ready to be merged for release should be submitted as a pull request to the relevant branch, for upcoming / in-development releases this branch would be the `master` branch, for historic/old releases (e.g. patching a bug on an older version) this would be the versions parked branch e.g. `v4.x.x`.
### Step 1: Clone the repository
```bash
git clone https://github.com/invertase/react-native-firebase.git
cd react-native-firebase
```
### Step 2: Install test project dependencies
```bash
yarn
yarn tests:ios:pod:install
```
> Note that this project is a mono-repo, so you only need to install NPM dependencies once at the root of the project with `yarn`.
## Testing Code
### Jest Testing
The project supports JS only testing through Jest. The following package scripts are exported to help you run tests;
- `yarn tests:jest` - run Jest tests once and exit.
- `yarn tests:jest-watch` - run Jest tests in interactive mode and watch for changes.
- `yarn tests:jest-coverage` - run Jest tests with coverage. Coverage is output to `./coverage`.
### End-to-end Testing
The project has a Detox powered `e2e` testing app located in `/tests`.
See it's local testing guide [here](https://github.com/invertase/react-native-firebase/blob/master/tests/README.md) to get started
with `e2e` testing this project.
---
## Submitting code for review
All code changes should be submitted as a pull request to the master branch.
The bigger the pull request, the longer it will take to review and merge. Try to break down large pull requests in smaller chunks that are easier to review and merge. It is also always helpful to have some context for your pull request. What was the purpose? Why does it matter to you? Tag in any linked issues.
@@ -122,25 +135,41 @@ To aid review we also ask that you fill out the PR template as much as possible.
> Please use draft pull requests if the pull request is not yet complete.
### Your PR title
We use the [Conventional Commits](https://www.conventionalcommits.org/) format throughout the project. Your Pull Request title should be
in this format; however your commits themselves do not need to follow this format as all PRs are eventually squash merged.
#### Examples
- `docs(analytics): added extra example for logEvent`
- `tests(perf): should throw invalid arg error`
- `fix(firestore,android): fixed NPE crash`
- `feat(functions): add support for function timeouts`
See the [Conventional Commits](https://www.conventionalcommits.org/) specification for more information.
### Code review process
Pull Requests to the protected branches require two or more peer-review approvals and passing status checks to be able to be merged.
Pull Requests to master require two or more peer-review approvals and passing status checks before they can be merged.
When reviewing a Pull Request please check the following:
Reviews of Pull Requests are based on the following acceptance critical:
- Does the PR provide cross-platform support?
- i.e. adding a new feature then does the implementation provide iOS and Android support.
- Pull Requests should not be merged or approved unless both platforms are supported (unless the feature is specific to one platform only)
- Pull Request is not still tagged as `WIP` if it's ready to be merged/reviewed
- Pull Request follows the Firebase Web SDKs API/implementation
- In some instances this is not always possible e.g. Firebase Module does not exist in the Web SDK, such as `crashlytics()` or the implementation can't work (or not performant) in the React Native environment, such as `storage().putString()`
- Types
- Have flow types been added?
- Have Typescript types been added?
- Does the PR provide docs
- Have `e2e` tests been updated or new tests been added to test newly implemented or changed functionality.
- Does the PR provide valid change log entries
- i.e. if adding a new feature then does the implementation provide iOS and Android support.
- Pull Requests should not be merged unless both platforms are supported (unless the feature is specific to one platform only)
- Pull Request follows the Firebase Web SDKs API/implementation.
- In some instances this is not always possible.
- If APIs have changed;
- Has the documentation been updated?
- Have the TypeScript types been added?
- Have the tests been updated or new tests been added to test newly implemented or changed functionality.
- E2E tests.
- Other tests through Jest.
- Do all CI checks pass.
### [No Brown M&M's](http://en.wikipedia.org/wiki/Van_Halen#Contract_riders)
Once a PR is merged into master; new versions of the changed packages are automatically created and published to NPM.
If you made it all the way to the end, bravo dear user, we love you. You can include the 🔥 emoji at the bottom of your ticket to signal to us that you did in fact read this file and are trying to conform to it as best as possible: `:fire:`.
## [No Brown M&M's](http://en.wikipedia.org/wiki/Van_Halen#Contract_riders)
If you made it all the way to the end, bravo dear user, we love you. You can include the 🔥 emoji at the bottom of your issue or PR to signal to us that you did in fact read this file and are trying to conform to it as best as possible: `:fire:`.

3
tests/.babelrc
View File

@@ -4,8 +4,9 @@
[
"istanbul",
{
"cwd": "..",
"instrument": true,
"relativePath": false,
"relativePath": true,
"include": ["**/packages/**"],
"useInlineSourceMaps": false
}