What packages belong in react-native-community?
TheSavior opened this issue · comments
Introduction
There have been some requests lately for adding repositories to react-native-community. I'd like for the org to have some guidelines as to what should be in the org. When should existing repos be moved in? When should new packages be created first in the org vs starting outside?
From my perspective, almost all of the modules that currently exist in the org to fall into these categories:
- Modules that were initially in core but separated out (cli, WebView, AsyncStorage, etc...)
- Packages used to support these modules (react-native-circleci-orb, docker-android, bob)
- Repos maintaining the larger community of React Native (discussions-and-proposals, upgrade-helper, releases)
The requests I've seen recently don't fall into one of these existing categories but instead need a new category. Something like:
- Modules that seem important to the ecosystem, but the existing repo / maintainers are viewed by some users as not meeting their needs
Do we want to expand the scope of react-native-community to be a home for these modules?
I worry about react-native-community becoming a centralized org that most of the react-native modules want to be in. I'm even more nervous about bringing in repos or forks of repos that are currently under-maintained.
I would rather see these modules become healthy on their own, and if they can't because the existing maintainers are unreachable, then for a fork to become healthy. If that isn't possible then being in the react-native-community org doesn't seem like it would solve the problem itself.
Concrete Proposal
My concrete proposal is that the org stays focused on the three existing categories. However, is also willing to accept new modules to the org only if they are already well maintained by multiple people and very common in the community.
Examples of such modules are:
- Expo's set of well supported modules
- react-navigation/react-navigation
- wix/react-native-navigation
- kmagiera/react-native-gesture-handler
- software-mansion/react-native-reanimated
Thoughts?
I'm curious for any thoughts the community has. I wasn't around at the beginning of this org so I don't have context on the original purpose. I also work on the core and don't write many apps with RN as a user, so I'm not exactly sure how people perceive this org and if my perspective is inconsistent with that.
Thanks for writing this up! Just for reference, let me past here some thoughts I had around this topic the other day:
From my perspective, RNC is a bit like standard library - provides high quality modules to work with React Native that guarantee certain level of performance, stability and maintanance (now or in the future - we will not left important modules behind). It contains the most useful modules, most important ones and things that you will need sooner or later working with React Native.
provides high quality modules to work with React Native that guarantee certain level of performance, stability and maintenance
I agree with this. Modules in the org should have a certain quality bar and be well maintained. I wouldn't want to add new modules to the org that we don't feel confident can hit this bar.
It contains the most useful modules, most important ones and things that you will need sooner or later working with React Native.
Yeah, I think it includes some of the most commonly depended on / important modules, but there are many very important modules outside the org. In fact, I think some of the most important modules actually live outside. I think typically the most commonly depended on / important modules got that way because they have a healthy set of maintainers already. Just to list a few:
- Expo's set of well supported modules
- react-navigation/react-navigation
- wix/react-native-navigation
- kmagiera/react-native-gesture-handler
- software-mansion/react-native-reanimated
I do agree though that if the maintainers of these modules asked for them to be moved into the react-native-community org, that would be a reasonable thing for us to consider.
The requests we typically see aren't from modules like these, they are from modules that are under-maintained, hoping to become maintained by being in the org.
I updated my initial post with a concrete proposal including these thoughts.
I agree with the overall direction here. A couple of additional thoughts to consider:
- It may be worthwhile to articulate what react-native-community is not trying to be in addition to defining what it is. For example: react-native-community is not an organization of modules and components that round out the set of APIs towards a minimum viable product offering for building most react-native apps.
- While a centralized org. is probably not in the best interest of fostering a thriving community, there is still a need for publishing some recommendations on what qualities makeup a well-maintained module and for customers of react-native to be able to find/filter/navigate the vast ecosystem more meaningfully. We have been discussing about this topic and will have some proposals here shortly - I just want to tease here that whatever we come up with together should apply to the modules that do get added to react-native-community organization.
provides high quality modules to work with React Native that guarantee certain level of performance, stability and maintenance
I agree with this. Modules in the org should have a certain quality bar and be well maintained. I wouldn't want to add new modules to the org that we don't feel confident can hit this bar.
+1. Part of the motivation for having modules in react-native-community is the implicit (or explicit) expectations around quality.
I'd assert that part of the motivation for having this discussion is the customer need to know which modules are of the highest quality/well maintained/supported/etc. A tangential way to help establish this list could be through secondary tools like https://www.native.directory/
I'd suggest three metrics for deciding which repos to include:
- Popularity, eg. npm weekly downloads
- Code quality, repo maturity. Subjective decision by scanning through the files and making sure everything's reasonable
- Invested and involved maintainers. This one is crucial. It's worth noting that we're having trouble maintaining some of the existing RNC repos already. Some examples:
react-native-push-notification-ios,react-native-clipboard
Hey everyone.
Thanks for opening this conversation - I swear I'll try to to be brief in my response. As conversations on this subject of packages in the community (& guidelines around them) and the role have been opened in the past (I won't repeat what was written there for sake of brevity, but I would suggest that reading them to get a better overview is key for the success of this topic):
- Migrating a repo into the React Native Community
- Guidelines for community packages
- Documenting community components
- React-native-community & React-community: let's talk about them <- in particular I would recommend this to understand how the current iteration of RNComm came to be
From my perspective, almost all of the modules that currently exist in the org to fall into these categories:
I'm a bit surprised by this phrase, as I find it quite different. The 3 categories you mention are only represent less than 50% of the repositories in the organisation - and most of the other repositories are instead what you define as a "new" category of
Modules that seem important to the ecosystem, but the existing repo / maintainers are viewed by some users as not meeting their needs
Just to mention a couple: lottie-react-native, react-native-maps, *-tab-view, *-svg etc etc. (there are at least 35 of these) and a good portion of them were in the org before any of the ones belonging on the 3 categories above.
This is because the original thought is in line with @grabbou's POV.
All of this said, I agree that there should be a series of "metrics" to use when deciding if to "accept" an "application to RNComm" - and on this topic I agree with @Ashoat, in particular with his 3rd point (for the second one I would suggest that at least two different people would validate that in order to avoid single-person-biases).
I will not dive on the "whys" and "hows" of packages joining the RNComm for brevity sake (since the question is only about "what"), but I can confirm that what @stmoy says about "expected quality" is one of the reason there should be "relevant" packages in the org.
Last 2c$: untying a repository (+npm publish rights) from a single person but having it in an org is crucial for the long term sustainability of said package.
All of this said, this kind of decision is tied to some sort of governance and since it's "rooted' on members of the community actively working on these libraries I would suggest reviving these conversations (or to start new ones):
I think one type of repo that should definitely be in react-native-community are meta-repos. Meta repos are repo that provide guidelines and tooling for creating react-native libraries.
One example is https://github.com/brodybits/create-react-native-module.
Especially considering there were code decisions made in the cli based on what this repo was doing.
I would personally also love to see a awesome-react-native type list hosted in react-native-community that includes known libraries that follow guidelines and are expected to work with most rn-community tooling without issues.
Meta repos are repo that provide guidelines and tooling for creating react-native libraries.
@akshetpandey there was an attempt at that with this repo -> https://github.com/react-native-community/.github but sort of died of starvation in a way
My brain played a trick on me and made me look at this problem in "another direction": what if there was another org for all the packs that don't belong in the RNComm, but that would still provide the basic idea of moving libs out of the ownership of a single authors? Like, something like an asylum/cattery of sort? This maybe could also be like, the minor league to RNComm's major league in a way? Where a certain libs learns/grows/validate itself (in terms of community wanting it, etc) to the point of being able to "graduate" into the RNComm?
Idea: have an (somehow official) react-native org + react-native-community ?
How can I join react-native-community?
@codler this is not the right place to ask. There is not a precise way, but you can read more about it here though -> rnc-archive/.github#46
@codler this is not the right place to ask. There is not a precise way, but you can read more about it here though -> react-native-community/.github#46
Thanks for pointing to right direction, its hard to find the right place.
Hi everyone, discussing this issue lugg/react-native-config#382 the maintainer gave me permission in this repo and in the npm. I came here to ask if we should migrate to react-native-community or invite more maintainers to help me to maintain this package. What do you think?
I think you should do what is best for that project assuming it isn’t part of this org. If that means bringing on more people to maintain the project that would be a good idea regardless of what Org it was in. :-)
@luancurti I personally think it's a good candidate to be adopted by the community. It's proven to be a pretty critical part of the RN ecosystem and I'd like to see the maintenance responsibilities be shared more broadly
I think a repo such as luggit/react-native-config should be a community repo, since it provides android and iOS environment and build functionality, and solves vital security issues for variables in native code which JS devs wouldnt be familiar with. It's standing out as the only repo that provides all of this functionality, and it already has a growing community where it currently lives.
To add to the discussion about what defines a repo that belongs in react-native-community I think it should have at least some of the following:
- It solves either a very common problem or a common piece of functionality
- It already stands out as a leading / popular repo, with a solid community and online discussion behind it
- the community would clearly benefit from the functionality, and the repo would benefit from the exposure to the community
- and extra points for any repo that provides native code functionality or build tools that JS devs wouldn't be familiar with
I noticed no more repos are being added until this discussion has reached a conclusion, although the discussion is already 4 months old. In my opinion this in unproductive. I would say adding and removing repos should be done as things evolve or react-native release out of the box features. How to deal with deprecating repos can be discussed when they arise by the community.
Just peeping in to this discussion, I was brought here after looking at the handoff issue on react-native-config. I agree with @conor909 - letting this discussion lull is a bottleneck.
Hey folks, I know it's not a real update on this conversation and I've not been super involved in RN the last few weeks, but I've seen in the Core Contributors Discord that this is indirectly being discussed on... hopefully over the next month or so there is going to be a clearer guideline on this topic.
Come on, guys... It's already mid July almost and still no progress/clarity on adopting react-native-config into the react-native-community..
Can we please get this going as more and more developers are waiting on this???
For such a big and active community it shouldn't take months to make a decision and onboard this.
Why are developers waiting on this? Why are they unable to use react-native-config today?
@TheSavior The owner hasn't got time to maintain it, and I suppose no one person wants to take it on. You can see this issue lugg/react-native-config#382
In the meantime, I'd recommend https://github.com/maxkomarychev/react-native-ultimate-config
Disclosure: I am the author of alternative solution https://github.com/maxkomarychev/react-native-ultimate-config.
@TheSavior The owner hasn't got time to maintain it, and I suppose no one person wants to take it on. You can see this issue lugg/react-native-config#382
The ownership has already been transferred, and there's a number of
developers that are willing to contribute and maintain it and/or looking to
get their pull-requests merged.
What will be different when/if package is moved to community? What prevents people from community to open pull requests in the original repository? It looks like @luancurti is a member of the community and he has permissions.
There is alternative solution https://github.com/maxkomarychev/react-native-ultimate-config and why should react-native-config be moved and not react-native-ultimate-config instead?
Btw, there is a story of a successful fork (not even transferring) of the repo to new author: from https://github.com/wkh237/react-native-fetch-blob to https://github.com/joltup/rn-fetch-blob and it happened without react-native-community being involved. And new one beats the original in npmtrends. So if people are willing to maintain a project it can be done without react-native-community.
@maxkomarychev this discussion isn’t about react-native-config, it’s about the direction of react-native-community, but the point is it’s already been counterproductive since people were waiting on an outcome on this discussion for months before someone decided to take on the config project. It seems this discussion was the cause of the slow process for that particular package, but potentially more
Personally, I would prefer that the RN community org does not grow larger - in terms of number of repos that are in it, but rather smaller, if possible. From my (limited) experience, when a library is in the RNC it
(1) gives the module a "premium badge" just because of its presence in RNC - whereas in reality, any module can be great regardless of what GH org it is in.
(2) Users assume that if a module is in RNC, it is top quality - and that may or may not be true. Some modules are in great shape, others like datetimepicker have a lot of work that needs to be done - I say that as that module's maintainer. This may negatively affect the orgs perception.
(3) Kinda related to (2) - I feel like because a module is in RNC, folks might assume it has "a team of maintainers" - which is not automatically true, and from my experience in datetimepicker, outside contributions do not happen as often as I'd expect.
Thank you everyone for sharing your perspective and insight to help work through this issue! This question has now been answered in the "What repositories belong in React Native Community?" doc.
To learn more about the decision process, refer to "Partner organizations and the React Native Community organization".
To learn more about the plan for moving towards the new state of the React Native Community organization, refer to "Plan for applying the new React Native Community repository policy".
In summary:
- The organization will contain repositories that act as forums for structured discussions and/or provide information about React Native and the ecosystem. These repositories may be purely textual, or they may be tools like the Upgrade Helper and React Native Directory, depending on what is better suited for the job. The only exception to this is React Native CLI, which will continue to live in React Native Community as long as the maintainers believe this to be the best home for it.
- We will start migrating other repositories out of the React Native Community organization and npm scope as described in the plan document. We know that changing package names can be challenging and a difficult transition for the ecosystem. We will take care to support the community through this migration as best as we can.
Hi all. Arrived here after noticing packages like NetInfo are now under their own org, .e.g. https://github.com/react-native-netinfo/react-native-netinfo, posting this after an hour of researching why.
Some of the main reasons behind the lean core initiative were said to be:
- reduce the bundle size
- reduce app size
- reduce dev dependencies
- make the core codebase more accessible
Ownership of the modules was never in question; one would assume the modules would still have some kind of blessing or support from the core RN team even as they moved to separate repos.
The two docs linked above say this solves the issue of arbitrarily blessing specific solutions, but I think most of us users considered that a feature, not a bug™. Ownership and quality concerns are briefly touched but not really addressed in those.
I find it concerning that essential platform features such as net-info, async-storage, camera-roll, notifications, geolocation, clipboard access, are now all independent projects. There are expectations from core-sanctioned libraries - you know they will meet some baseline for testing, CI, cross-platform support, etc and be part of at least one [important app]'s test suite - that cannot be consistently met by independent repos (emphasis on consistently).
These are foundational features for almost every application, not custom extensions, and there is barely any reason for competing libraries to exist in those spaces; so looking back at the original reasons it feels like throwing the baby out with the bathwater. It will hurt the experience of developing and maintaining a RN app by pushing the burden of finding & vetting libraries for basic platform features, plus making sure they are always compatible and up-to-date onto the users. Is that a desirable change?
Thanks for sharing that @ricardobeat. I absolutely see where you are coming from and the desire to continue having "core-sanctioned" libraries.
Your comment implies that we've historically not communicated the reality of the situation, and lulled people into a false sense of security. This change brings to the surface this reality for us to figure out how to move forward as a community.
When all of these modules were built in to React Native, they were essentially unmaintained, even though to those using React Native they didn't look that way. FB didn't use them, none of the maintainers were familiar with the code and were afraid of changing it, and thus PRs didn't get merged because of that risk of breakage.
So they moved out of core. Among the reasons you quoted, it also to removed FB as the gate keepers of this code, and to let people more changes more confidently.
In the react-native-community org a lot of contributors stepped up and jumped in to these modules, but it wasn't any more "sanctioned" by core, by FB, or by the other partner companies. And while these maintainers did an amazing job with a bunch of these modules, many of the modules in the org stopped being maintained because the contributors stopped using them at their work, or numerous other reasons.
At the same time, there have been other modules outside of core, or outside of the community that may be better maintained and have more features. Some examples are from the amazing modules that Expo maintains. But even though they are perhaps better modules, because they aren't in core, they appear "unsanctioned" and thus, to the detriment of the products teams build, they aren't being chosen.
So we are moving the modules out of the Community org. These modules aren't being maintained by fewer people, and aren't any less supported. But now perception can match the reality.
And with that, we can move on to helping the community focus on discoverability and deciding on the right package for their needs. That's one of the goals of reactnative.directory that we've been working on. We think this will be healthier and more sustainable in the long run than the approaches we've taken before.
I hope that makes some sense. I'm happy to hear if you have more thoughts and concerns. We want to do the right things here. 🙂
@TheSavior thanks for the context! I really did not know that, had the assumption that these were developed in parallel with the core as standard platform features, and took the intent to unbundle at face value.
FB didn't use them
That is surprising - I can't picture a released app that does not use net info, clipboard or persistent storage. Does FB really not have a need for those, or just use custom private modules?