[hryhoriiK97]

Why & how

For monorepo entries, file checks (hasReadme, hasChangelog, etc.) only looked at the package subdirectory files fetched via the GraphQL files field. This means monorepo packages whose README (or other community files) lives at the repo root were incorrectly marked as not having one.

Example: react-native-enriched-markdown has its githubUrl pointing to packages/react-native-enriched-markdown/, which contains no README. The README lives at the repo root, but the scoring criterion "Has a README file" was not matched — even though the README is clearly present both on GitHub and npm.

The fix falls back to rootFiles (the repo root listing, already fetched for monorepo entries via @include(if: $fetchRoot)) for hasReadme, hasChangelog, hasContributing, hasCC, and hasSecurity. For non-monorepo packages, rootFiles is null, so the fallback safely returns false with no behavior change. This is consistent with how packageManager detection already falls back to rootFiles.

✅ Checklist

• Added library to react-native-libraries.json
• Updated library in react-native-libraries.json

• Documented how you found or replicated the issue.
• Explained how you fixed the issue or built the feature.
• Described how to use or verify the change.

[Simek]

Hey @hryhoriiK97, thanks for the content on the changes and logic update! 👍

It's a fine workaround for metadata, but this still does not guarantee the presence of those files in the package (since not everyone have a bundle pipeline which puts them in the package). Ideally, in the future we should check the presence of some files like README and LICENSE in the npm package itself, and not in the repo.

Also, those flags are not only used for scoring, I would need to tests if the files correctly load in Markdown tabs, where we render files on the website.