Correctif de sécurité : fichier de verrouillage binaire de Bun

Ce que cela signifie

Renvoyée par POST /orgs/{org}/code-security/deps/findings/{id}/autofix (Correctifs de sécurité). Aucune pull request n’a été demandée.

Le même refus est renvoyé avec le type security-fix-binary-lockfile par POST /orgs/{org}/dependency-updates/security-fixes/requests. Les chemins ci-dessus sont obsolètes et continuent de renvoyer autofix-binary-lockfile jusqu’au 2027-10-15. Basez votre logique sur l’un ou l’autre type.

Exemple de message detail renvoyé avec cette erreur :

• This repository uses bun.lockb, Bun’s binary lockfile, which only Bun itself can rewrite. Run bun install --save-text-lockfile once to switch to bun.lock (Bun 1.2 and later write it by default); security fixes work on bun.lock.

La réponse contient aussi "reason": "binary_lockfile".

Que faire

Le résultat a été lu dans bun.lockb, le fichier de verrouillage binaire de Bun. Seul Bun peut le réécrire, et fremforge n’exécute jamais les outils d’un dépôt pour un correctif de sécurité : aucune pull request n’est donc ouverte.

Passez le dépôt au fichier de verrouillage texte de Bun : exécutez une fois bun install --save-text-lockfile et commitez bun.lock (puis supprimez bun.lockb). Bun 1.2 et versions ultérieures écrivent bun.lock par défaut. Les correctifs de sécurité fonctionnent alors sur bun.lock ; voir Écosystèmes pris en charge.

Forme de la réponse

Toutes les erreurs de l’API fremforge sont au format problem+json de la RFC 9457 :

{
  "type": "https://docs.frem.sh/reference/api/errors/autofix-binary-lockfile",
  "title": "Unprocessable Entity",
  "status": 422,
  "detail": "...",
  "reason": "binary_lockfile"
}

Basez votre logique sur type, et non sur title ou detail : ces champs sont destinés à être lus par un humain et peuvent être reformulés.