rnc-archive/.github

This repository contains the general guidelines for the RNCommunity org

.github's Issues

TODO: complete the guidelines

Currently just added the stubs so that the actual fillings can be discussed through PRs.

Some example/sources:

• https://github.com/Moya/contributors
• https://github.com/golang-standards/project-layout
• https://github.com/facebook/graphql/blob/master/CONTRIBUTING.md
• https://github.com/ocaml-community/meta
• https://github.com/Microsoft/TypeScript/wiki/Contributing-to-TypeScript
• https://jaxenter.com/dos-donts-keeping-changelog-147373.html
• https://boats.gitlab.io/blog/post/rust-2019/

No Option to start a Tabs project without Typescript

Feature request

Why it is needed

No one should be forced into using Typescript and the tabs project is a nice way to start. Starting out, I found the tabs project essential to learning and I'm sure others would benefit from it. To force someone to use Typescript is an unfair disadvantage whether they aren't interested in using it in general or are new to Javascript.

It used to be available

Possible implementation

Code sample

How to handle AndroidX conversion in libraries, with react-native 0.60

There has been some discussion on Discord about how to support react-native-community module consumers on both sides of the AndroidX divide in the transition from react-native 0.59 to 0.60

The general problem is that react-native native modules are included in the Android build system as source generally, and all the Java source in a project must be using either AndroidX or the support libraries, but they may not mix.

So if a module converts to AndroidX and distributes as source, the only way to use the module in your project is to convert your project to AndroidX. It is reasonable to assume there are projects that either cannot do this, or cannot do it immediately, implying that we will be stranding those projects on old module versions for any module that converts to AndroidX.

I do not believe there has been consensus on how to support non-AndroidX and AndroidX projects at the same time, but the ideas I have seen so far are:

• convert module to AndroidX, then use some tool (bob?) to generate AAR for distribution and run reverse jetifier
• maintain module with support libraries and distribute as AAR so consumers may use Jetifier
• have a postinstall script that does a translation using something like this https://developer.android.com/topic/libraries/support-library/downloads/androidx-class-mapping.csv
• maintain separate branches (tagged @androidx or @support or similar)

I'm interested in the AAR ideas but I'm unsure of the exact mechanics to generate an AAR, distribute it, and how to document AAR integration into a project.

Take over : react-native-orientation

Don't know where to notice, that the maintainer wan't that "we" (react-native-community) take over his repository.

yamill/react-native-orientation#376

Mabye add an "How to" in our Readme.md how to:

1. Suggest to take over other Projects to r-n-c
2. Become a Member/Maintainer in r-n-c

(BTW: Please add me to the Community, so that I can support it.)

Repository organisation guidelines

Introduction

Hey Everyone! Today I planned to re-implement several of deprecated modules via new ones created within react-native-comunity. I soon came to realisation that currently each repo within community is different from one another in various aspects and hence wanted to discuss possibility of unifying them in order to provide consistent experience.

The Core of It

• Some packages lost their typescript definitions once they were extracted from main rn project, since @types/react-native covered pretty much whole codebase.

• .podspec files for iOS are sometimes located either in root of the repository or inside ios folder.

• Some packages have ci process set up in place, others don't

• Packages have different eslint configs, some try to use react-native-community preset, but add extra rules or overwrites

• README files are very different in terms of headline order / having or not having demos, their language style etc...

• Folder organisation is different, some use lib for main code, some use src. Some repos have examples, others don't.

Discussion points

Would it be a good idea to come up with structure / examples of repo organisation for react-native-community in order to make each package more familiar to the user and ensure all of them deliver consistent quality? Or will something like this harm creativity / velocity of maintainers?

TODO: complete the decisions around common health files

Since we are going enforce those through GitHub allowing for organization-wide community health files, we need to finalise the decisions around them.

From the link

You can add CONTRIBUTING, SUPPORT, CODE_OF_CONDUCT, ISSUE_TEMPLATE(S), or PULL_REQUEST_TEMPLATE(S) files to a public, organization-owned .github repository, and if a given community health file doesn’t exist for a repository, the organization-wide default will be used.

Need to settle on:

• CONTRIBUTING
• SUPPORT
• CODE_OF_CONDUCT
• ISSUE_TEMPLATE(S)
• PULL_REQUEST_TEMPLATE(S)

Permissions

Not sure if this is the format of issues that works for you (feel free to close it), but we should also talk about permissions, on npm and Github, for projects and whole organisation.

Can we have a drawing pad or signature pad?

Feature Request

There is react-native-signature-signature-pad or some other drawing pad, those are great but they are quite outdated now. May we have them be improved and included in react-native-community package? Also can we have it for RN for Windows and RN for Web support too?

https://github.com/RepairShopr/react-native-signature-capture

Good reasons why your company should get involved

This is a spin off conversation around point 4 from #41 - after I gave my talk at ChainReact last week (video will be updated as some point), I got some cool feedback and a few people asked for resources / a playbook on how to help them explain to their managers / colleagues why having their company involved in Open Source, and in particular in the React Native Community org, would benefit them.

I've read my fair share of articles on the subject, but in here I'd like to try and follow an approach similar to the one used here react-native-community/discussions-and-proposals#134.

Meaning, each comment in this conversation should follow this basic template (feel free to copy paste!):

## The real good reason

And here is some more details about that precise reason

Getting involved in the React Native Community

Introduction

This wants to basically be a "better written version" of the answer I tend to give to people that ask me "how can I get involved in the RNComm" and variations - hoping that this can serve as a baseline to then turn the whole conversation into something we can put in the guidelines.

The core of it

Basically, active involvement in the React Native Community can be sort of defined in one of these three roles:

External contributor

This is the easiest / broadest "bucket" - anyone who submits a PR to any of the repos without having any level of permissions on it is here.
The PRs could be about anything, from fixing a bug to improving the README, and usually it's a 1-PR-and-go scenario (also called "drive-by" in some other oss project).

If an external contributor instead keeps "coming back", and shows that they are interested in helping / that they are passionated about the project - which usually means submitting more good quality PRs, they can be turned in...

Internal/core contributor

This kind of contributor is different in two ways from the external one:

1. they have write auth in the repo
2. they are overall responsible for keeping the codebase in a good state, in ways like
   1. submittings PRs to keep the repo up to date VS react native
   2. publishing new versions
   3. work on releases / update / write the changelogs
   4. adding toolings for things like CI
   5. reviews PRs

Maintainer

Lastly, maintainers - they differ from core contributors in a number of ways:

1. they only require read level of permissions over the repo (of even the new triage role which is still in beta) to get started
2. they are overall responsible for keeping the repo in an healthy state, which means doing things like
   1. reviewing PRs
   2. do issue grooming/triaing
   3. introduce & configure things like ProBots
   4. maintain the non-code files in a repo, ex. issue templates, CoC, README etc
   5. work on releases / update / write the changelogs

A way to become a maintainer is also to just start helping out in the issue section of the repo by answering to questions, providing repros and or suggesting workarounds - or even cc'ing in the maintainer on issues that can be closed.

---

All of this said, usually the core contributor and maintainer are collapsed, and in most conversations even in this repo, they are completely interchangeable. I just wanted to, here, point out the difference because it may provide more roads and more opportunities for new introducing new people that are interested in only some of those things.

Also, basically, both roles are reachable via being a good OSS citizen, by showing interest and commitment 🤗

Discussion points

Please feel free to add roles, tasks and change the ones I described above - I literally mostly free flow wrote everything above so I'm sure it will not be complete or perfect 😅

Could not resolve project :react-native-camera.

Could not determine the dependencies of task ':app:compileDebugJavaWithJavac'.

Could not resolve all task dependencies for configuration ':app:debugCompileClasspath'.
Could not resolve project :react-native-camera.
Required by:
project :app
> Cannot choose between the following configurations of project :react-native-camera:
- generalDebugApiElements
- mlkitDebugApiElements
All of them match the consumer attributes:
- Configuration 'generalDebugApiElements':
- Required com.android.build.api.attributes.BuildTypeAttr 'debug' and found compatible value 'debug'.
- Found com.android.build.api.attributes.VariantAttr 'generalDebug' but wasn't required.
- Required com.android.build.gradle.internal.dependency.AndroidTypeAttr 'Aar' and found compatible value 'Aar'.
- Required org.gradle.usage 'java-api' and found compatible value 'java-api'.
- Found react-native-camera 'general' but wasn't required.
- Configuration 'mlkitDebugApiElements':
- Required com.android.build.api.attributes.BuildTypeAttr 'debug' and found compatible value 'debug'.
- Found com.android.build.api.attributes.VariantAttr 'mlkitDebug' but wasn't required.
- Required com.android.build.gradle.internal.dependency.AndroidTypeAttr 'Aar' and found compatible value 'Aar'.
- Required org.gradle.usage 'java-api' and found compatible value 'java-api'.
- Found react-native-camera 'mlkit' but wasn't required.

Migrating a repo into the React Native Community

We should really define "once and for all" what the flow for this should be, so that we can write it somewhere & communicate to people who wants to go for this.

At the moment, over time it sort of became standard to open an issue in the D&P repo, similar to what happened in this situation:

react-native-community/discussions-and-proposals#135

I wonder if this should happen instead on this repo, so that it's not "noising" the other discussions.

Note: I don't want here & now define "what it takes" to have a repo join the Comm, just "the happy path". This other topic is probably literally a case-by-case scenario.

BOTs in the org

Basically, it seems that via this repo we can also share some probots configurations - since that the bots are installed at org level.

We are trying this feature out via the stalebot and this PR: #29

But potentially we could also do other things, here are a couple of examples we could get some inspiration from:

• https://github.com/ansible/ansible/blob/devel/.github/BOTMETA.yml
• https://github.com/home-assistant/codeowners-mention

If you have any ideas on something that we could automate via bots, to make life easier for the maintainers in the repo, please post them here!

Maintainers Permission over the repo they maintain

Following up from #5, as pointed out by @sibelius the maintainers of each repo (as indicated here https://github.com/react-native-community/.github/blob/master/MAINTAINERS.md) should have admin access to "their" repo.

Any cons to this? We should still strive to balance this with #46

Standardise folder organisation and naming

Familiar file organisation can go long way in terms of viewing and updating codebase.
We have different main code names for folders i.e. src vs lib, native code being nested in various subfolders etc..

I really enjoy how well structured react-native-firebase project is https://github.com/invertase/react-native-firebase/tree/master/packages

If you look inside any of these packages you will find same structure all across the board. I feel its very welcoming to contribute to and clear.

Sustainability in the React Native Community

Introduction

This is the successor of react-native-community/discussions-and-proposals#58. It was probably not the right place nor the right time, but lately I've been hearing more conversations around issues connected to this so I feel it's time to re-open the conversation for @react-native-community/maintainers to give their opinions.

This is a small extract from my personal experience being in RN & OSS for a year and a half, so please if you see something that doesn't sound correct/fair please comment below!

The core of it

Over the past few months we have seen a steady increase of maintainers and repositories in the React Native Community org (table), one of the main reasons being the Lean Core extractions, which has put some important components in the hands of the community. This required to bring the org itself to a more consistent state, that spawned repos like this one—and efforts like the one described in #40.

This also bubbled up how some repositories are actually not in a healthy state, for many different reasons. In talking with other maintainers some or all of these themes keep recurring:

• usually a person is the only one working on the repo (both code, issue triaging, etc)
• doesn't have free time to spare anymore
• there is a change in priorities
• doesn't have the drive to work on the repo anymore, because they stopped using it in prod

While these are all valid reasons to stop being actively involved in any open source project, there's usually some "negative concerns" that are part of the reason some people stop working on a project, without providing real closure or a "happy ending." We have currently have nothing in place to prevent this from happening again and again.

This is not a unique problem of the RNComm org, it's a systematic issue in the entire Open Source ecosystem. And these reasons are usually connected to the fact that this work is being done on top of a full time job, and usually involves little to zero compensation.

All of these interconnected issues are known to lead to overworking, mental health issues, and ultimately burnouts, which is something that we—as a community and an organisation and ultimately a group of people who care for each other—should try to avoid.

The big question

How can we ensure that the task of being a core contributor and a maintainer for a repository in this org is not a stressful and negative experience, while keeping said repository in a healthy state (code is up-to-date, issues are being handled, PRs are being merged, etc), given also their relevance for the broader community of React Native developers?

Discussion points & potential solutions

As you may imagine, this is a highly complex, multi-dimensional problem. I'll try to describe a few different aspects and/or different plans here:

1) Reduce the workload per person

This could be done by adding more maintainers in each repo. As mentioned above, a healthy repository would have, in an ideal world—just to mention a few points:

• code that is up-to-date with the latest RN releases
• issues that are being replied to and/or triaged
• PRs that are getting reviewed and merged
• changelogs and releases being pushed out, managed, and communicated well

This could also happen by integrating bots and CI/CD, which is something that we are already actively trying to work on (for instance, see #30.)

2) Introduce some org-level money influx

This means, most likely, to introduce an OpenCollective or something similar, that is managed at the level of the organisation, in which each repo would be a "subdivision" of the overall org. (I don't know the precise terms)

This would give companies using the repositories an easy way to "give back" via money, sponsorships, or donations; Consequently this enables maintainers to dedicate time more sustainably and consistently, or at least to get some acknowledgement and compensation for their work.

The main concern I have is that in other instances the collected funds couldn't be used to directly pay for any development work (see Roads and Bridges, pag 111). This issue kept coming up in discussions on this subject that I've had about this approach, which does reinforce my concerns.

Something along these lines is currently happening in react-native-camera, but I don't have any further details on the matter, (cc @sibelius would you like to give us some insights on how this is working out for you?)

3) Introduce some "personal" level money influx

We could assist maintainers to go down the road of direct sponsorships via services like Patreon, or, more recently, GitHub Sponsor.

This, also, would lead to a more sustainable way for some maintainers to being involved in OSS without dedicating all their free time, or at least without getting something in return for their time.

This approach doesn't suffer from the problem of having to divide donated funds amongst recipients fairly. But, at the same time, it may make it more difficult for some companies to donate due to the bureaucracy involved. It will also likely suffer from "organic" imbalance problems as developers would receive donations based on their visibility and reach.

4) Introduce more corporates / stakeholders

The core idea behind this fourth approach is for companies relying on React Native & React Native Community libraries to get more involved in sustaining them. There are two different approaches I could imagine working,

4a) a direct approach

This is best exemplified by some companies like Callstack or GoDaddy "adopting" some repositories. In doing so they allow the maintainers that are part of their workforce to be able to work on projects during their working hours. (At least that's my understanding of how it works. I may be wrong)

Another way would be for companies to directly put bounties on issues via services like IssueHunt or by publishing grants, similar to what Google did for web frameworks.

4b) an indirect approach

This category consists of companies that have special benefit programs or schemes that allow their employees to work on Open Source in a sustainable way with some amount of either time or compensation in return. For example, Formidable has a program called Sauce which pays employees for their time spent on Open Source outside of working hours. Futurice is running a similar program and has been for a while called Spice.

spinoff thread about good reasons why a company would want to become a stakeholder: #52

---

This is all I could think of on this subject. I probably forgot some things worth mentioning. Please contribute to this conversation, share your experience! I'd love to hear different opinions and more ideas on the matter!

how to move react-native-qrcode-scanner to be a @react-native-community package instead

Question

Well, a few time ago, I've joined as a maintainer to react-native-qrcode-scanner package, to maintain it over @moaazsidat, which it's creator and owner of such package, but has not been possible anymore to keep maintaining this library that has a lot of people using over react-native-camera, that usually just needs of a QR code scanner built-in. And discussing with him about how we should go ahead with such a project, and move forward with it, we came up to a conclusion that it would be better to have entire support from @react-native-community instead of keeping supporting just by us as we have been because we don't have a maintainers team behind the scenes, especially because this package it's not a project apart, but actually, a wrapper to react-native-camera, with a few adaptions to just QR codes scanning use-cases. Therefore, in general, both are almost the same thing, even because currently, this package doesn't interact directly to native-side, but just uses features around react-native-camera that allows by default along with barcodes, QR codes been scanned as well.

So, you might be thinking, why then is this project so important to the point of being moved to @react-native-community? Alright, one of the main reasons is that a lot of people of react-native-camera has been using that package to the only purpose of scan bar and QR codes, and a pretty simple fact around it, is that this project can be a huge use-case to finally get started to re-write the entire core of react-native-camera to support the scale all the features that have been built in the last few years, thanks of course, to the profound contributions made by a lot of people around the world, but unfortunately, have been turned the core of react-native-camera less extensible, and hard to compose.

So, the idea here would be to have react-native-qrcode-scanner on @react-native-community not to just keep maintaining it, but also, to re-write their API, and approach as well, to compose such functionality of scanning codes be integrated on a new react-native-camera API core.

I hope had to be pretty clear about what's our idea, which it's by the way, a thing that I've been discussed a lot in the last few months with the people related to such projects, as such @sibelius @moaazsidat @mauriciord

Governance in the React Native Community

Introduction

This conversations wants, in synergy with #41, to try starting a "second phase" of the React Native Community "renaissance". The first phase kicked off with the Lean Core effort, and culminated in react-native-community/discussions-and-proposals#63.

Over the last 6 months, we are seeing how that "stuck the landing" and the challenges that have surfaced since.

The core of it

The React Native Community organisation, for historical reasons, never had a clear governance model.

This led to a series of issues, most of which are well described in "The tyranny of structurelessness":

As long as the structure of the group is informal, the rules of how decisions are made are known only to a few and awareness of power is limited to those who know the rules. Those who do not know the rules and are not chosen for initiation must remain in confusion, or suffer from paranoid delusions that something is happening of which they are not quite aware.

In our precise scenario, there is also to keep in mind that most of us are core contributors and maintainers in voluntary form, during our free time: it's understandable that to add, on top of this, the task of being part of a decision making process could be something that some people simply don't want to be involved with.

We have been trying to work around this structurelessness in the past few months, and more than a few issues in this very repository are attempts to discuss guidelines that every maintainer can follow.

Moreover, via repositories like this that can rollover health files (#3), by introducing bots (#30), having a template when generating new repo, a CLI to simplify targeting platforms (https://github.com/react-native-community/bob) and a CircleCI Orb to provide an easy start for CI we have been trying to support each other and reduce the amount of "overheard" that supporting a RN library can have.

We have also took care some long overdue "chores":

• we finally have a rough 'map' of who-is-maintaining-what (check maintainers.md)
• every maintainer is a member of the repo (#40), and part of the @react-native-community/maintainers team
• we have an active twitter account (@ReactNativeComm)
• and an official rncomm email account (up to a few months ago, the org was still attached to the personal email of an old maintainer not active in RN anymore)

But still, without any clear governance, it's usually up to the person who kicks off a discussion to transform it into something actionable; and in more than a few cases, given the low response, these conversation end up staling up and no action is taken on them (for example: #34).

We should try to change that - to quote The tyranny of structurelessness again:

For everyone to have the opportunity to be involved in a given group and to participate in its activities the structure must be explicit, not implicit. The rules of decision-making must be open and available to everyone, and this can happen only if they are formalized.

The big question

What would be a governance model for this organisation that, while keeping a lean structure, would not make members feel forced into decisions?

Discussion points & potential solutions

I don't have a precise idea of what would be the best approach here: if a few people were responsible for taking those decision, it would surely remove the burden from every maintainers to keep up with all the conversations and comment on them (and, honestly, most of them already don't - as mentioned a few times already).

But at the same time, it may lead to scenarios where some maintainers would feel left out / not feel heard.

To mention The tyranny of structurelessness once more, I think that the principles described in the last section are something we should try to keep in mind.

Another interesting idea I've read, when it comes to instead a flat governance approach, is the one described by Roman Imankulo, used at Doist:

Rough consensus isn’t majority rule. It’s okay to go ahead with a solution that may not look like the best choice for everyone or even the majority. “Not the best choice” means that you believe there is a better way to solve the problem, but you accept that this one will work too. That type of feedback should be welcomed, but it shouldn’t be allowed to slow down a decision.

But of course I'm sure there is plenty of other options - among which:

/tinfoil hat section

Way out there - and, again, WAY OUT THERE - there is also a possibility for this problem to be connected to #41, as proposed by Harry Tormey:

I think the key to organizational support is aligning interests between the community and the organizations. Perhaps a voting system with tiered recurring donations? I.e if company x donates y $ they can vote on prioritizing bugs.

This is an approach used in some foundations and organisations, and I first actually heard about it when discussing the release process for the main React Native; I can't remember precisely where, but I'm sure it was something that was considered when trying to think for different alternatives for the cherry-pick/release patches process - given the line in the sand that the FB team has on this topic.

But, again, this is just to throw some more ideas at the wall to sparks conversations.

/end tinfoil hat section

---

This is all I could think of on this subject. I probably forgot some things worth mentioning. Please contribute to this conversation, share your experience! I'd love to hear different opinions and more ideas on the matter!

Discussion: Standardise the release process

We should have a standard process for releasing new versions of modules.

TODO: Complete Maintainers file

Let's complete the table with the full list of repositories in the org and the maintainers and status.

PR code review guidelines

We should mention in the guidelines that anyone can review the PRs (to free some load from the maintainers) but int he same time the release and merge procedures are restricted so we can keep the builds in a working state.

Discussion: Utilise GitHub actions to automate various processes

Looking at some other issues here related to automating releases / enforcing certain checks it is clear that we will need some common ci solution for all of these.

I would usually go for circle, but have recently switched my personal projects to GitHub actions and thus far only limitation there was that Docker can't run macOS environment.

Otherwise, process is very simple and creating your own actions doesn't take much effort either.

Hence I thought about proposing this for repos within React Native Community (At least some of them that don't have CI yet?).

We could create new repository here that could house custom actions created by the community, so they are easily accessible to every maintainer as well ass have examples for different workflows, including main one that community might accept as a standard?

Utalising these will mean we can easily add things like Danger since we won't need to fiddle with github permission token generation (actions expose one as default secret), nor will we need to set up each repo on a third party ci service.

What do you guys think? If this is interesting it might be worth to enrol react-native-community into Github Actions Waiting list (if it is not there yet) https://github.com/features/actions

about metro bundle when start it close immediatly

In the event of a new project with four days' time, all the solutions were tested with no useful solution. If the problem was solved by the problem, the problem is that the Metro server bundle is a reaction-native run. -android opens up a second and disappears. I am a genius for four days. I have never had a sincere solution, and for knowledge I tried to change the port for live instead of 8081 for any number that is the same.

• Edit: any project old is play , when i create any new project didn't work .
  

NPM publish maintainers

We should have 2 maintainers + backup that are allowed to publish on npm.

There are cases where the modules have only one maintainer with rights and this can become a bottleneck when he or she is not able to push.

Migrate react-native-config to community

Question

How we can migrate the react-native-config to the community? Who can help me? I have permission on the npm package and write in the repository

Security reporting procedures not on community repos nor this meta repo

Question

How can we make security contacts and procedures clear in community repos?

There is no security contact listed in most if not all community repos.

Adding the security info for community repos in a SECURITY.md in each repo and in this meta repo would help security researchers find the appropriate security contact.

Based on info in this Twitter thread, community repos are not in scope for Facebook's security program. However, this is not indicated anywhere in the community repos.

A SECURITY.md in each repo and in this meta repo with text similar to this would suffice:

To report security issues in React Native Community repos, please check the repo's SECURITY.md or contact each repo's listed maintainers directly via email. Community repos are out of scope for Facebook's security program.
To report security issues in React Native, contact Facebook's Security team at facebook.com/whitehat.

For a more concrete example, I had difficulties identifying who to contact for a security issue in a react-native-community repo which was previously part of React Native core. Having clear reporting info in each repo would have helped, because the security scope distinction between the community repos and core repos was not immediately clear to me. I almost reported the issue to Facebook's security team thinking it was in scope of their security program, before being told otherwise on Twitter.

I filed a parallel issue for the https://reactnative.dev website since some community repos have old docs still hosted on there, and the website was my second stop after not finding info in the community repos: facebook/react-native-website#1889

Discussion: Removing "react-native" from repo names and moving packages to @react-native-community

Proposal

I want to propose 2 changes, that (in my opinion) could further improve "consistency" feeling around react-native-community org

1. Strip react-native from package names under react-native-community since organisation name already implies it.
2. Bring all packages under @react-native-community/ namespace in package registry

Discussion

1. How would maintainers feel about this?
2. Difficulties that can be caused by renaming repos in GitHub and possible solutions to solve them?
3. Difficulties that can be caused by renaming / moving packages into @react-native-community/ namespace and possible solutions to solve them?
4. And in general is this something worth doing due to effort it requires (do all maintainers need to do this or can one person make the change across the org?)

Present status

There are several examples that show case this proposal within the community already: cli, apple-sign-in, art etc..

I also mentioned this in react-native-svg repository via software-mansion/react-native-svg#1021

Organisation updates - PLEASE READ ❤️

👋 folks!

As you may have noticed, I've (finally!) managed to work on #1 and finish it - if something doesn't look right submit a PR and/or let me know!

Aside from that, I've also added all the maintainers to the github org and to a team called Maintainers. This should have happened gradually when you were added as maintainers for any of the orgs, and it was long overdue and I'm sorry it took me so long to push this forward.

(btw in case now you are receiving notifications for all the repos in the org, I'd recommend to simply unwatch the ones you are not working on 🤗)

All of this should help you all to keep track of things going on, and finally recognise you as part of the community 🤗

A few more comms, in case you missed:

• if you are not in the React Native Contributors discord, please let me know!
• there is an eslint config all repos should use, you can read more here #2
• we are working on a template that can be used to quickly create new repos https://github.com/react-native-community/template
• and many more things, please look at open issues!

Lastly, as members of the comm, as discussed in #5, you can quickly jump around and help each other; I'd suggest that, following this change in auth, you do a couple things in your repo:

1. Add a codeowners file
2. via the settings lock the master branch from direct commits (optional)
3. set the PRs to require a review by one of the code owners, like so (in settings -> branches):

(to do this, btw, you need to be admin role in the repo you maintain - if you are not, please let me know and we'll fix that too!)

For anything, feel free to open an issue here or write in the Discord - see you around 👋

Handling github issues

Right now there is no common or "standard" way of handling the github issues in the community modules. Each module does it differently but maybe we should be try to unify this in a consistent behaviour.

Some modules are more complicated than other and attract many issues that are just questions or "not working" which waste the maintainers time.

For an initial triage few steps could be implemented:

• determine what kind of issue a user can open (github seems to do this easily with the template files, like here: https://github.com/react-native-community/react-native-netinfo/issues/new/choose)
• create/reuse a bot that would parse the issue and force them respect the templates we put in place (fastlane for example has a nice one)
• implement some rules for stale issues (close them after a while)
• extend the bot to filter "+1", "me too", "same here" type of comments

Please add any comments/ideas you might have 🤗

[Proposal] Add Github Discussions to React Native repo

Why it is needed

I think this will help us provide solutions to the most common problems that the React Native repository presents in terms of issues. Also, it will allow users to find the solutions to their problems easier and will reduce the number of duplicate issues.

sample

white s

Question

Version release for react-native-text-input-mask

Hi,

Not sure if this is the right place to ask this question.

But react-native-text-input-mask package seriously need to release a new version with componentWillReceiveProps fix #141 which is already merged in the repo but a version has not been release yet.

Is there anyone who have the rights to release the version or ask the maintainer to do so?

Invariant Violation: Element type is invalid: expected a string (for built-in components) or a class/function (for composite components) but got: object. You likely forgot to export your component from the file it's defined in, or you might have mixed up default and named imports.

Question I am working on EXPO app which has predefined tabs. I added firebase authentication with a new page Loginscreen. js in the app. However, it is throwing error now in app.js file. Here is my App. js file

import { AppLoading } from 'expo';
import { Asset } from 'expo-asset';
import * as Font from 'expo-font';
import React, { useState } from 'react';
import { Platform, StatusBar, StyleSheet, View } from 'react-native';
import { Ionicons } from '@expo/vector-icons';
import AppNavigator from './navigation/AppNavigator';

export default function App(props) {
const [isLoadingComplete, setLoadingComplete] = useState(false);

if (!isLoadingComplete && !props.skipLoadingScreen) {
return (
<AppLoading
startAsync={loadResourcesAsync}
onError={handleLoadingError}
onFinish={() => handleFinishLoading(setLoadingComplete)}
/>
);
} else {
return (

{Platform.OS === 'ios' && }


);
}
}

async function loadResourcesAsync() {
await Promise.all([
Asset.loadAsync([
require('./assets/images/robot-dev.png'),
require('./assets/images/robot-prod.png'),
]),
Font.loadAsync({
// This is the font that we are using for our tab bar
...Ionicons.font,
// We include SpaceMono because we use it in HomeScreen.js. Feel free to
// remove this if you are not using it in your app
'space-mono': require('./assets/fonts/SpaceMono-Regular.ttf'),
}),
]);
}

function handleLoadingError(error) {
// In this case, you might want to report the error to your error reporting
// service, for example Sentry
console.warn(error);
}

function handleFinishLoading(setLoadingComplete) {
setLoadingComplete(true);
}

const styles = StyleSheet.create({
container: {
flex: 1,
backgroundColor: '#fff',
},
});

Error message

Invariant Violation: Element type is invalid: expected a string (for built-in components) or a class/function (for composite components) but got: object. You likely forgot to export your component from the file it's defined in, or you might have mixed up default and named imports.

Check the render method of App.

• node_modules/react-native/Libraries/Renderer/oss/ReactNativeRenderer-dev.js:5715:8 in createFiberFromTypeAndProps
• node_modules/react-native/Libraries/Renderer/oss/ReactNativeRenderer-dev.js:5743:14 in createFiberFromElement
• ... 8 more stack frames from framework internals

Not really sure what I am doing wrong!!

THIS IS MY AppNavigator file

import React from 'react';
import {createAppContainer, createSwitchNavigator, createStackNavigator } from 'react-navigation';
import LoginScreen from '../screens/LoginScreen';
import MainTabNavigator from './MainTabNavigator';

const AppNavigator = createStackNavigator(

{ Login: LoginScreen},

{ Main: MainTabNavigator},
);

Invariant Violation: Element type is invalid: expected a string (for built-in components) or a class/function (for composite components) but got: object. You likely forgot to export your component from the file it's defined in, or you might have mixed up default and named imports.

React native environment setup issue in Apple M2 Pro

I am new to React native development in Mac M2 pro. I started React native environment set up. But all the time I face this issue
"✖ Installing Ruby Gems
error Looks like your iOS environment is not properly set"
Tried to resolve with cocapods and gemfile fixes.
I am also tried to resolve as per online guidelines still not getting solution. Kindly help to resolve issue to start my react native journey. Thanks in advance

Lean Core repositories

👋 everyone.

I was checking the repositories to understand how many are from the Lean Core and, unless I've made mistakes, there are 25 repositories out of the 70 in the org that have been generated via this effort:

• art
• async-storage
• cli
• jsc-android-buildscripts
• react-native-button
• react-native-cameraroll
• react-native-checkbox
• react-native-clipboard
• react-native-datetimepicker
• react-native-geolocation
• react-native-image-editor
• react-native-image-picker-ios
• react-native-masked-view
• react-native-netinfo
• react-native-picker
• react-native-progress-bar-android
• react-native-progress-view
• react-native-push-notification-ios
• react-native-segmented-control
• react-native-simple-share
• react-native-slider
• react-native-statusbar
• react-native-tvos
• react-native-viewpager
• react-native-webview

An issue I've noticed about them is that the way the repos "say" they are part of the Lean Core / come from the Lean Core is different, and a bit inconsistent. I mean, some don't even say it - here are a few examples:

• https://github.com/react-native-community/react-native-masked-view
• https://github.com/react-native-community/react-native-slider#migrating-from-the-core-react-native-module
• https://github.com/react-native-community/cli

I'd propose that we create a simple tag like https://img.shields.io/badge/PRs-welcome-brightgreen.svg?style=flat-square and we use that across all the different repos 🤗

Standardise type definitions

Right now we have several repos that include both flow and ts definitions, or just single one or none.

It would be awesome to come up with guidelines for adding these definitions into the repositories (i.e what folders should they go in, what file names should be used etc...)

Some definitions will probably need to be created from scratch, some can be ported from @types/react-native package (since there are now packages that are untyped due to extraction from main rn repo).