I Wanted to Pay My Dependencies. Only One of Three Registries Would Let Me Find Out Who to Pay.

A small tool the author uses to normalize package metadata across npm, PyPI, and crates.io was used to investigate whether it was possible to find out how to pay the maintainer of a dependency using only the registry's public API. The author expected that this would be straightforward, as GitHub Sponsors, Open Collective, and other funding mechanisms were commonly mentioned in READMEs. However, the results revealed that each registry had a different relationship with the idea of structured funding data.

npm has a field called "funding" in its package.json file, which is implemented as an RFC and can be accessed using a command-line tool. Out of 25 well-known packages, 9 had the funding field filled in, but the shape of the data was inconsistent. Some packages provided a typed object, while others had a bare string or even multiple GitHub Sponsors URLs. This inconsistency made it challenging to write code that would reliably access this field.

PyPI, on the other hand, provides funding information through its project_urls key, which is free-form text entered manually by the maintainer. There is no reserved "funding" key or a specific schema for this data. PyPI's funding information is scraped from the project's web page, making it prone to human error and inconsistent labeling. Out of 20 packages checked, only 8 had a funding URL, and the shape of the data varied based on how the maintainer labeled it.

crates.io does not have a built-in way to access funding information for packages. The sparse index, which is the flat-file format that cargo uses for dependency resolution, does not include any specific fields for funding. The only way to access this information would be through crates.io's separate REST API, which is not accessible through the tool used in this investigation. This lack of support for funding data on crates.io surprised the author, given the platform's popularity among Rust developers.