Monorepo Dependents: hide unwanted entries and show combined usage

[hyochan]

🏷️ Discussion Type

Question

Body

I'd like to see all public repositories that use any package in the OpenIAP monorepo in one place. It contains react-native-iap, expo-iap, flutter_inapp_purchase, and scoped OpenIAP protocol packages. GitHub Support directed me to Community.

1. Remove or hide unwanted package entries

The Dependents package selector still includes:

• github.com/hyodotdev/openiap
• openiap-commerce-protocol

The unscoped npm package openiap-commerce-protocol is already deprecated; its current replacement is @hyodotdev/openiap-commerce-protocol. The repository currently has no go.mod, and I don't know why the github.com/hyodotdev/openiap entry appears.

How can I remove or hide these entries from this repository's selector? Can GitHub correct the package associations or refresh the index? This request concerns the displayed associations, not unpublishing packages or deleting source files.

2. Combined dependents for the monorepo

The public sidebar's Used by section currently represents only react-native-iap. I can choose another single package, but that still leaves out users of the other packages. The Dependents page also requires switching between packages.

Is there a setting, API, or workaround to provide:

• One browsable list of repositories using any of the monorepo's supported packages, with the relevant package names shown for each repository.
• One aggregate Used by count and link in the public repository sidebar.
• Deduplication: a repository using several packages counts once.

If this isn't supported, please consider a monorepo-wide or selectable package-group view as product feedback. It would let maintainers and visitors see where the whole project is used at a glance.

[Kushan20070126]

There are two separate limitations here.

For the unwanted package entries, I don't think there is a repository setting that lets a maintainer manually hide or delete individual entries from the Dependents package selector. GitHub builds the dependency graph from package/manifests and package metadata, so an unexpected package association is something GitHub would need to correct or re-index rather than something you can normally remove from the UI.

The github.com/hyodotdev/openiap entry is particularly worth reporting to GitHub if the repository has no go.mod, because Go modules are one of the sources GitHub's dependency graph can recognize. If GitHub is associating it incorrectly, Support would need to investigate the package-to-repository mapping.

For the second part, GitHub currently doesn't appear to support a monorepo-wide aggregate "Used by" view.

GitHub's documentation explicitly says:

The "Used by" section represents a single package from the repository.

For repositories containing multiple packages, an administrator can choose which package the counter represents under Settings → Advanced Security → Used by counter, but that is still one package at a time.

So there isn't currently a native setting that would produce:

OpenIAP monorepo
├── react-native-iap
├── expo-iap
├── flutter_inapp_purchase
├── @hyodotdev/openiap-commerce-protocol
└── other packages

Used by: 1,234 repositories

with repositories using multiple packages deduplicated into one count.

The Dependents view can show repositories that depend on packages in the repository, and it has package filtering, but GitHub still treats the package relationships individually.

For the aggregate view, I'd definitely frame this as a feature request rather than something that can be configured today. A useful proposal would be a package-group selector such as:

Dependents
[ All packages ]

Repository        Packages used
repo-a            react-native-iap, expo-iap
repo-b            flutter_inapp_purchase
repo-c            expo-iap, @hyodotdev/openiap-commerce-protocol

The important part would be deduplicating repositories while retaining which packages each repository uses.

For the incorrect/deprecated package associations, I'd open a separate Support request and include the exact package names, repository URL, and Dependents URLs. That keeps the data/indexing problem separate from the product-feedback request for an aggregate monorepo view.

[Sagargupta16]

1. The github.com/hyodotdev/openiap entry is not Go. The dependency graph names Swift Package Manager packages by repository URL, and your repo has a Package.swift at the root, so that entry is the SPM identity of openiap itself. Alamofire shows the same shape: github.com/Alamofire/Alamofire sits beside its npm-style package in the selector. It currently lists 0 dependents and will fill in only if a public repo's Package.resolved references your repo.

2. You cannot hide or remove selector entries. The list is every package name the graph has resolved to this repository from other repositories' manifests and lockfiles, and openiap-commerce-protocol stays as long as any public lockfile still pins the deprecated unscoped name. Deprecating on npm does not touch it, and a re-index would rebuild the same list from the same lockfiles.

3. There is no combined view, no aggregate "Used by" count, and no dependents API at all (nothing in REST or GraphQL returns dependents; the counts on the page are documented as approximate). The only knob is Settings, General, "Used by counter", where an admin picks which single package the sidebar shows. So keep that on your largest package.

If you want one deduplicated list for the README, the practical route is a scheduled Actions job that runs a code search per package name ("react-native-iap" path:package.json, flutter_inapp_purchase path:pubspec.yaml, and so on) and writes the union to a file. It is a different data source from the dependency graph, but it is the only one you can script.

Your product-feedback ask (a monorepo-wide package group view) is the right framing for the rest; nothing in the current UI gets there.

[iamyakay]

There isn't a documented setting to hide individual packages from the Dependents selector. Deprecating openiap-commerce-protocol doesn't remove references in consumers' manifests or lockfiles, so that entry may still represent valid usage.

The github.com/hyodotdev/openiap entry could be associated with Swift rather than Go. Your repository has a root Package.swift, and GitHub supports Swift dependency detection through Package.resolved. GitHub would need to confirm the ecosystem behind that package ID before determining whether the association needs correcting. A refresh alone wouldn't guarantee either entry disappears.

For combined usage, the native “Used by” counter supports one selected package, not a group. There also isn't a documented public dependents API that provides the combined, deduplicated list.

A separate page linked from your README could list repositories, show which packages each uses and deduplicate by repository ID. Code search can help collect that data, but search limits and indexing coverage mean it would be a partial list. It also wouldn't change the native sidebar count.

So the combined list and sidebar count require a GitHub feature change. Your proposed selectable package group, with repositories counted once and their package names retained, directly addresses that limitation.