[Discussion] Ideas to improve react-native-directory

[brentvatne]

What should change about this project to make it more useful? Let us know!

[dabbott]

This is a cool project! I like the concept a lot, and it's already great for discovering libraries. I have a few misc ideas:

For discovery

1. A Twitter account that posts a weekly or monthly digest of new libraries added (or with updates, getting popular, etc)

   I feel like I saw reactnative.directory at some point like a year or more ago and then forgot about it... if it were also a way to keep tabs on cool new libraries, I think I would find it more useful and it'd be more top-of-mind when I go digging for a library

For library insights

2. Expose the react-native version(s) from the package.json

   I often peek at these to get a sense of health. Maybe it should go into the health score... although sometimes people will only have "*", so not sure.

3. A 1-click Snack/Appetize where possible

   This would be AMAZING. I'm so much more likely to try a library with a 1-click demo. This could even be opt-in on the library author side... like a link in the package.json or extract any snack links from the README or something. Even if only a handful have it, it'd still be great.

4. Automated tests that run against react-native@latest

   Not sure if this is realistic, but that'd be so cool. I mean, even just showing if a library has tests would be a useful health indicator. BUT imagine if it also had to pass a yarn && yarn add react-native@latest && yarn test. I know there could be other misc libraries that might conflict (e.g. expo not running on @latest), so it would need to be opt-in.

Misc

5. Support GH emojis? No more :carousel_horse:

[brentvatne]

A Twitter account that posts a weekly or monthly digest of new libraries added (or with updates, getting popular, etc)

I love this idea! Something we should explore automating for sure.

Expose the react-native version(s) from the package.json

I often peek at these to get a sense of health. Maybe it should go into the health score... although sometimes people will only have "*", so not sure.

I'm torn on the React Native dependency - I think this is often not very useful. If you use a fork (eg: people using managed workflow with Expo, and many people using React Native that are willing to get their hands dirty), you will get unnecessary peer dep warnings. If you use an alpha or rc release, same thing applies (npm/npm#8854). I'd rather there be some concept outside of peerDependencies that expresses version compatibility, but that's another topic...

A 1-click Snack/Appetize where possible

We actually have this already! It's the examples field in react-native-libraries.json. Something tricky here is that these go out of date pretty quickly as React Native versions change. Maybe it would be better if people provided a URL to a source file that we can load into Snack, so they can keep that up-to-date in their own GitHub repo easily and then we just pull it in to Snack and attempt to load it with the latest version (if the library and examples are kept up to date in the repo, this should be fine!). We do this in the React Navigation documentation - when you click to run an example in Snack we just pass the source URL to Snack and then it pulls it in. 💡

Automated tests that run against react-native@latest

Flutter's pub.dev actually does something like this 😮 Check out the score analysis tab for this random Flutter package: https://pub.dev/packages/android_alarm_manager#-analysis-tab-

Support GH emojis? No more :carousel_horse:

Yep! @jonsamp

---

To be totally honest, I don't have a lot of time to dedicate to this. I'm trying to get the ball rolling because it feels like there really is a gap here in the React Native ecosystem, but we could use some help. If anyone wants to get involved and work on the great suggestions that @dabbott provided please don't hesitate to reach out here or on Twitter @notbrent.

[YashM20]

Proposal

1. Display Dependencies (Direct Dependencies)

   • Show the key dependencies that each package relies on.
   • Example: For @react-navigation/native, display its reliance on react-native-screens and react-native-safe-area-context.
   • reason: This helps developers to know which packages they need to install first.

2. Package Size Information

   • Add information about the package size, including:
     • Minified size
     • Gzipped size
     • Impact on app bundle size
   • Rationale: Size information helps considering performance implications and make trade-offs between functionality and app size.

Schema Updates

It requires extending the current schema as follows:

{
  // ... existing fields ...

  // ... new fields ...
  "dependencies": [ ],
  "size": {
    "minified": "<SIZE IN KB>",
    "gzipped": "<SIZE IN KB>",
    "impact": "<ESTIMATED IMPACT ON APP BUNDLE SIZE IN KB>"
  }
}

What are your thoughts on this?

[dongsuo]

The "Updated 1 month ago" comes from the Github repo. I suggest the time from npm would be better.