feat: Add line-specific comments functionality #21
Conversation
gary-van-woerkens
force-pushed
the
feature/line-comments
branch
from
26d2c40 to
3e180b0
Compare
|
Review the following changes in direct dependencies. Learn more about Socket for GitHub.
|
|
| - A comprehensive overall summary of the PR in the "summary" field | ||
| - Multiple specific comments targeting different issues with accurate file paths and line numbers | ||
| - Detailed explanations in each comment's body | ||
| - Code suggestions where appropriate |
There was a problem hiding this comment.
Il faut peut-être lui fournir un exemple de "code suggestion" parce que c'est dépendant de la plateforme où est faite la PR. Pas sûr que gitlab et github utilisent le même format en gros.
Là comme on lui dit pas que c'est du github en plus, il va pas forcément savoir quoi faire.
| // Extract response from tool use | ||
| // Find content blocks that are tool_use type | ||
| for (const content of message.content) { | ||
| if (content.type === 'tool_use') { |
There was a problem hiding this comment.
Si c'est pas content.type === 'tool_use' on veut peut-être log une erreur ou un warning ?
Aussi, je viens de voir le fallback à partir de la ligne 94. Je me suis fait un peu surprendre parce que je me serait attendu à voir le fallback direct dans cette premier boucle sur les message.content.
Là on fait 2 boucles, ce qui n'est pas bien grave mais qui est (je trouve) inattendu.
| // Find content blocks that are tool_use type | ||
| for (const content of message.content) { | ||
| if (content.type === 'tool_use') { | ||
| if (content.name === 'provide_code_review' && content.input) { |
There was a problem hiding this comment.
Pareil ici, si il nous fait utiliser un outil qui n'existe pas ou que input est vide, on peut peut-être log ça.
Aussi, provide_code_review devrait peut-être venir d'un enum de tools histoire de rendre les changements de noms de tools plus simple ? J'ai pas d'énorme conviction là dessus, je trouve juste que c'est un poil plus propre, je te laisse décider.
| content: prompt | ||
| } | ||
| ], | ||
| tools: [ |
There was a problem hiding this comment.
Je me dis que ça pourrait être bien d'avoir un tool utils capable de construire un objet JSON "anthropicToolDefinition" (ou openAI, Mistral, LLaMa plus tard) automatiquement. Sinon on va devoir réécrire et maintenir cet objet dans chaque sender qui communique avec anthropic et dès qu'un tool va changer un peu ça risque de devenir embêtant à maintenir et source d'erreurs.
On peut commencer simple avec une fonction qui renvoie simplement :
{
name: 'provide_code_review',
description:
'Provide structured code review with line-specific comments',
[Reste de l'objet...]
}
| interface CodeReviewResponse { | ||
| summary: string | ||
| comments: Array<{ | ||
| path: string | ||
| line: number | ||
| body: string | ||
| suggestion?: string | ||
| }> | ||
| } |
There was a problem hiding this comment.
Je pense que j'aurais plutôt mis ça dans le même fichier que le tool "provide_code_review" vu que c'est lié à ça plutôt qu'au lineCommentsSender, non ?
| * @param prompt - The prompt to send to Anthropic | ||
| * @returns The text response from Anthropic | ||
| */ | ||
| export async function defaultSender(prompt: string): Promise<string> { |
There was a problem hiding this comment.
J'ai fait un commentaire plus bas qui permettrait d'éliminer ce defaultSender et de le remplacer par un "anthropicSender" avec les "tools" en paramètre optionnel.
| // Schémas de validation pour garantir le bon format de la réponse | ||
| const CommentSchema = z.object({ | ||
| path: z.string(), | ||
| line: z.number().int().positive(), |
There was a problem hiding this comment.
Je flag ça juste une fois maintenant : Là on bosse sur une seule ligne mais est-ce qu'on voudra mettre le temps nécessaire à la gestion d'un interval de lignes plutôt qu'une seule ?
Si oui, ça peut valoir le coup de prévoir des maintenant une "startLine" et une "endLine" peut-être ?
|
|
||
| if (!validationResult.success) { | ||
| console.error( | ||
| "Validation de l'analyse échouée:", |
There was a problem hiding this comment.
nit: Il devrait y avoir une espace avant et après le ":" en français.
| const existingSummary = await findExistingSummaryComment(context, prNumber) | ||
| if (existingSummary) { | ||
| // Update existing summary | ||
| await context.octokit.issues.updateComment({ | ||
| ...repo, | ||
| comment_id: existingSummary.id, | ||
| body: formattedSummary | ||
| }) | ||
| } else { | ||
| // Create new summary | ||
| await context.octokit.issues.createComment({ | ||
| ...repo, | ||
| issue_number: prNumber, | ||
| body: formattedSummary | ||
| }) | ||
| } |
There was a problem hiding this comment.
Le summary comment c'est la même chose que le global comment finalement non ? Est-ce qu'on réécrit pas du code pour rien ici par conséquent ?
| repositoryUrl: string, | ||
| branch: string, | ||
| templatePath?: string, | ||
| token?: string |
There was a problem hiding this comment.
Si c'est un "githubAccessToken" autant l'appeler comme ça pour être clair peut-être ?
No description provided.