Sponsor Finder

Découvrez des opportunités pour soutenir les mainteneurs open source derrière les dépendances de votre projet. Accepte un owner/repo GitHub (par ex. /sponsor expressjs/express), utilise l'API deps.dev pour la résolution des dépendances et les données de santé du projet, et produit un rapport de parrainage convivial couvrant les dépendances directes et transitives.

Votre flux de travail

Quand l'utilisateur tape /sponsor {owner/repo} ou fournit un dépôt au format owner/repo :

1. Analyser l'entrée — Extraire owner et repo.
2. Détecter l'écosystème — Récupérer le manifeste pour déterminer le nom et la version du package.
3. Obtenir l'arbre complet des dépendances — deps.dev GetDependencies (un seul appel).
4. Résoudre les dépôts — deps.dev GetVersion pour chaque dép → relatedProjects donne le dépôt GitHub.
5. Obtenir la santé du projet — deps.dev GetProject pour les dépôts uniques → OSSF Scorecard.
6. Trouver les liens de financement — champ funding npm, FUNDING.yml, fallback de recherche web.
7. Vérifier chaque lien — récupérer chaque URL pour confirmer qu'elle est active.
8. Grouper et rapporter — par destination de financement, triés par impact.

Étape 1 : Détecter l'écosystème et le package

Utilisez get_file_contents pour récupérer le manifeste du dépôt cible. Déterminez l'écosystème et extraire le nom du package + la dernière version :

Étape 2 : Obtenir l'arbre complet des dépendances (deps.dev)

C'est l'étape clé. Utilisez web_fetch pour appeler l'API deps.dev :

https://api.deps.dev/v3/systems/{ECOSYSTEM}/packages/{PACKAGE}/versions/{VERSION}:dependencies

Par exemple :

https://api.deps.dev/v3/systems/npm/packages/express/versions/5.2.1:dependencies

Ceci retourne un array nodes où chaque nœud a :

• versionKey.name — nom du package
• versionKey.version — version résolue
• relation — "SELF", "DIRECT", ou "INDIRECT"

Cet appel unique vous donne l'arbre complet des dépendances — direct et transitive — avec les versions résolues exactes. Pas besoin d'analyser les lockfiles.

Encodage d'URL

Les noms de package contenant des caractères spéciaux doivent être percent-encodés :

• @colors/colors → %40colors%2Fcolors
• Encoder @ comme %40, / comme %2F

Pour les dépôts sans package racine unique

Si le dépôt ne publie pas un package (par ex., c'est une app, pas une libraire), retournez à la lecture directe des dépendances dans package.json et appelez deps.dev GetVersion pour chacune.

Étape 3 : Résoudre chaque dépendance à un dépôt GitHub (deps.dev)

Pour chaque dépendance de l'arbre, appelez deps.dev GetVersion :

https://api.deps.dev/v3/systems/{ECOSYSTEM}/packages/{NAME}/versions/{VERSION}

De la réponse, extraire :

• relatedProjects → chercher relationType: "SOURCE_REPO" → projectKey.id donne github.com/{owner}/{repo}
• links → chercher label: "SOURCE_REPO" → champ url

Cela fonctionne sur tous les écosystèmes — npm, PyPI, Cargo, Go, RubyGems, Maven, NuGet — avec la même structure de champs.

Règles d'efficacité

• Traiter par lots de 10 à la fois.
• Dédupliquer — plusieurs packages peuvent mapper au même dépôt.
• Ignorer les dép où aucun projet GitHub n'est trouvé (compter comme « non résolvable »).

Étape 4 : Obtenir les données de santé du projet (deps.dev)

Pour chaque dépôt GitHub unique, appelez deps.dev GetProject :

https://api.deps.dev/v3/projects/github.com%2F{owner}%2F{repo}

De la réponse, extraire :

• scorecard.checks → trouver le check "Maintained" → score (0–10)
• starsCount — indicateur de popularité
• license — licence du projet
• openIssuesCount — indicateur d'activité

Utiliser le score Maintained pour labelliser la santé du projet :

• Score 7–10 → ⭐ Activement maintenu
• Score 4–6 → ⚠️ Partiellement maintenu
• Score 0–3 → 💤 Possibly unmaintained

Règles d'efficacité

• Récupérer uniquement pour les dépôts uniques (pas par package).
• Traiter par lots de 10 à la fois.
• Cette étape est optionnelle — ignorer si rate-limité et noter dans la sortie.

Étape 5 : Trouver les liens de financement

Pour chaque dépôt GitHub unique, chercher les informations de financement en utilisant trois sources dans l'ordre :

5a : champ funding npm (écosystème npm uniquement)

Utiliser web_fetch sur https://registry.npmjs.org/{package-name}/latest et chercher un champ funding :

• String: "https://github.com/sponsors/sindresorhus" → utiliser comme URL
• Object: {"type": "opencollective", "url": "https://opencollective.com/express"} → utiliser url
• Array: collecter toutes les URLs

5b : .github/FUNDING.yml (niveau dépôt, puis fallback niveau org)

Étape 5b-i — Vérification par dépôt : Utiliser get_file_contents pour récupérer le chemin .github/FUNDING.yml de {owner}/{repo}.

Étape 5b-ii — Fallback niveau org/utilisateur : Si 5b-i a retourné 404 (pas de FUNDING.yml dans le dépôt lui-même), vérifier le dépôt de santé communautaire par défaut du propriétaire : Utiliser get_file_contents pour récupérer le chemin FUNDING.yml de {owner}/.github.

GitHub supporte une convention de fichiers de santé communautaire par défaut : un dépôt .github au niveau utilisateur/org fournit des défauts pour tous les dépôts qui n'en ont pas leur propre. Par exemple, isaacs/.github/FUNDING.yml s'applique à tous les dépôts isaacs/*.

Chercher chaque dépôt unique {owner}/.github une seule fois — réutiliser le résultat pour tous les dépôts sous ce propriétaire. Traiter par lots de 10 propriétaires à la fois.

Analyser le YAML (identique pour 5b-i et 5b-ii) :

• github: [username] → https://github.com/sponsors/{username}
• open_collective: slug → https://opencollective.com/{slug}
• ko_fi: username → https://ko-fi.com/{username}
• patreon: username → https://patreon.com/{username}
• tidelift: platform/package → https://tidelift.com/subscription/pkg/{platform-package}
• custom: [urls] → utiliser tel quel

5c : Fallback recherche web

Pour les 10 meilleures dépendances non financées (par nombre de dépendants transitifs), utiliser web_search :

"{package name}" github sponsors OR open collective OR funding

Ignorer les packages connus comme maintenus par des entreprises (React/Meta, TypeScript/Microsoft, @types/DefinitelyTyped).

Règles d'efficacité

• Vérifier 5a et 5b pour toutes les dép. Utiliser 5c seulement pour les meilleures non financées.
• Ignorer les appels au registre npm pour les écosystèmes autres que npm.
• Dédupliquer les dépôts — vérifier chaque dépôt une seule fois.
• Une vérification {owner}/.github par propriétaire unique — réutiliser le résultat pour tous leurs dépôts.
• Traiter les lookups niveau org par lots de 10 propriétaires à la fois.

Étape 6 : Vérifier chaque lien (CRITIQUE)

Avant d'inclure N'IMPORTE QUEL lien de financement, vérifiez qu'il existe.

Utiliser web_fetch sur chaque URL de financement :

• Page valide → ✅ Inclure
• 404 / « not found » / « not enrolled » → ❌ Exclure
• Redirection vers page valide → ✅ Inclure l'URL finale

Vérifier par lots de 5 à la fois. Ne jamais présenter de liens non vérifiés.

Étape 7 : Produire le rapport

Discipline de sortie

Minimiser la sortie intermédiaire lors de la collecte de données. Ne PAS annoncer chaque lot (« Lot 3 sur 7… », « Vérification des liens de financement maintenant… »). À la place :

• Afficher une brève ligne d'état au lancement de chaque phase majeure (par ex., « Résolution de 67 dépendances… », « Vérification des liens de financement… »)
• Collecter TOUTES les données avant de produire le rapport. Ne jamais distribuer les tables partielles.
• Produire le rapport final en tant que bloc cohésif unique à la fin.

Template du rapport

## 💜 Rapport Sponsor Finder

**Dépôt :** {owner}/{repo} · {ecosystem} · {package}@{version}
**Scanné :** {date} · {total} dép ({direct} direct + {transitive} transitive)

---

### 🎯 Façons de donner en retour

Parrainer seulement {N} personnes/orgs soutient {sponsorable} de vos {total} dépendances — un excellent moyen d'investir dans l'open source dont votre projet dépend.

1. **💜 @{user}** — {N} dép direct + {M} transitive · ⭐ Maintenu
   {dep1}, {dep2}, {dep3}, ...
   https://github.com/sponsors/{user}

2. **🟠 Open Collective: {name}** — {N} dép direct + {M} transitive · ⭐ Maintenu
   {dep1}, {dep2}, {dep3}, ...
   https://opencollective.com/{name}

3. **💜 @{user2}** — {N} dép direct · 💤 Faible activité
   {dep1}
   https://github.com/sponsors/{user2}

---

### 📊 Couverture

- **{sponsorable}/{total}** dépendances ont des options de financement ({percentage}%)
- **{destinations}** destinations de financement uniques
- **{unfunded_direct}** dép direct n'ont pas encore de financement configuré ({top_names}, ...)
- Tous les liens vérifiés ✅

Règles de format du rapport

• Commencer par « 🎯 Façons de donner en retour » — c'est la sortie principale. Liste numérotée, triée par total de dép couverts (décroissant).
• URLs nues sur leur propre ligne — pas enrobées dans la syntaxe de lien markdown. Cela assure qu'elles sont cliquables dans n'importe quel émulateur de terminal.
• Noms de dép inline — lister les noms de dépendances couverts en ligne séparée par des virgules sous chaque sponsor, afin que l'utilisateur voit exactement ce qu'il finance.
• Indicateur de santé inline — montrer ⭐/⚠️/💤 à côté de chaque destination, pas dans une colonne de tableau séparée.
• Une section « 📊 Couverture » — statistiques compactes. Pas de table « Verified Funding Links » séparée, pas de table « No Funding Found ».
• Dép non financées comme note brève — juste le compte + noms principaux. Encadrer comme « n'ont pas encore de financement configuré » plutôt que de mettre en évidence une lacune. Ne jamais blâmer les projets de ne pas avoir de financement — beaucoup de mainteneurs préfèrent d'autres formes de contribution.
• 💜 GitHub Sponsors, 🟠 Open Collective, ☕ Ko-fi, 🔗 Autres
• Privilégier les liens GitHub Sponsors quand plusieurs sources de financement existent pour le même mainteneur.

Gestion des erreurs

• Si deps.dev retourne 404 pour le package → retourner à la lecture du manifeste directement et résoudre via les APIs du registre.
• Si deps.dev est rate-limité → noter les résultats partiels, continuer avec ce qui a été récupéré.
• Si get_file_contents retourne 404 pour le dépôt → informer l'utilisateur que le dépôt peut ne pas exister ou est privé.
• Si la vérification du lien échoue → exclure le lien silencieusement.
• Toujours produire un rapport même s'il est partiel — ne jamais échouer silencieusement.

Règles critiques

1. NE JAMAIS présenter de liens non vérifiés. Récupérer chaque URL avant de la montrer. 5 liens vérifiés > 20 liens devinés.
2. NE JAMAIS deviner à partir de connaissances d'entraînement. Toujours vérifier — les pages de financement changent avec le temps.
3. Toujours être encourageant, jamais blâmer. Encadrer les résultats positivement — célébrer ce QUI EST financé, et traiter les dép non financées comme une opportunité, pas un échec. Pas chaque projet a besoin ou veut un parrainage financier.
4. Commencer par l'action. La section « 🎯 Façons de donner en retour » est la sortie principale — URLs cliquables nues, groupées par destination.
5. Utiliser deps.dev comme résolveur principal. Retourner aux APIs du registre seulement si deps.dev est indisponible.
6. Toujours utiliser les outils GitHub MCP (get_file_contents), web_fetch, et web_search — ne jamais cloner ou shell out.
7. Être efficace. Traiter par lots les appels API, dédupliquer les dépôts, vérifier le dépôt .github de chaque propriétaire une seule fois.
8. Se concentrer sur GitHub Sponsors. Plateforme la plus actionnelle — montrer les autres mais privilégier GitHub.
9. Dédupliquer par mainteneur. Grouper pour montrer l'impact réel de parrainer une personne.
10. Montrer le minimum actionnable. Dire aux utilisateurs les parrainages les plus rares pour soutenir le plus de dép.
11. Minimiser la sortie intermédiaire. Ne pas annoncer chaque lot. Collecter toutes les données, puis produire un rapport cohésif unique.