28 lines
3.8 KiB
Markdown
28 lines
3.8 KiB
Markdown
---
|
|
name: roblox-feature-docs
|
|
description: Guider toute nouvelle fonctionnalité de ce projet roblox-ts en comparant les bibliothèques installées, leurs documentations actuelles et les API Roblox avant l'implémentation.
|
|
---
|
|
|
|
# Fonctionnalités guidées par la documentation
|
|
|
|
Pour chaque fonctionnalité, choisir la solution la plus adaptée au comportement demandé et aux versions réellement présentes dans ce dépôt. Le but est un code actuel, compatible et vérifié, sans ajouter une bibliothèque simplement parce qu'elle existe dans le template.
|
|
|
|
## Chercher avant de choisir
|
|
|
|
1. Comprendre le comportement attendu, les contraintes du jeu et l'emplacement client, serveur ou partagé. Examiner le code existant pour conserver ses conventions et éviter un second système pour le même rôle.
|
|
2. Consulter `package.json` et `pnpm-lock.yaml` pour les versions installées. Utiliser la section « Bibliothèques installées » du `readme.md` comme index de documentation, puis ouvrir seulement les sources pertinentes pour la fonctionnalité. Le README est un point d'entrée, pas une preuve que son lien décrit la version installée.
|
|
3. Vérifier les API et recommandations auprès des sources primaires actuelles : documentation officielle de Roblox pour le moteur, documentation, README, notes de version ou code du mainteneur pour une bibliothèque. Quand la documentation en ligne suit `main` ou la dernière version, chercher le tag correspondant à la version verrouillée et contrôler les déclarations/types dans `node_modules` avant d'écrire le code. Ne pas déduire une API du seul nom du paquet.
|
|
Si les sources en ligne sont indisponibles, utiliser les sources et types locaux et signaler que l'actualité de la recommandation n'a pas pu être vérifiée.
|
|
4. Comparer l'API Roblox native et les bibliothèques installées qui couvrent réellement le besoin. Pour des rôles qui se recoupent, comme le réseau (`@flamework/networking` et `@rbxts/net`) ou les interpolations (`@rbxts/ripple` et `@rbxts/tween`), choisir une approche cohérente avec le reste du projet et expliquer brièvement le critère décisif. Considérer compatibilité, maintenance, typage, coût d'intégration et comportement à l'exécution. Si rien d'installé ne convient, examiner une alternative maintenue avant d'ajouter une dépendance.
|
|
|
|
## Implémenter avec la bonne version
|
|
|
|
- Employer l'API confirmée pour la version installée. Si une meilleure approche exige une version plus récente, vérifier les changements et la compatibilité ; mettre à jour la dépendance et le lockfile lorsque cette évolution sert la fonctionnalité, puis valider la migration. Ne pas copier aveuglément un exemple de la dernière documentation dans un projet épinglé sur une version antérieure.
|
|
- Garder les responsabilités Roblox au bon endroit : décisions de jeu sensibles côté serveur, interface et effets locaux côté client, contrats partagés explicites. Valider les données qui traversent le réseau et libérer connexions, tâches et instances selon le cycle de vie de la fonctionnalité.
|
|
- Ajouter uniquement les dépendances nécessaires. Préférer les primitives du moteur ou les systèmes déjà adoptés quand ils répondent aussi bien au besoin.
|
|
|
|
## Vérifier et rendre compte
|
|
|
|
- Pour une modification de code, exécuter au minimum `pnpm check`, `pnpm format:check` et `pnpm build`. Ajouter des tests ciblés lorsqu'ils vérifient un comportement significatif ; tester aussi dans Roblox Studio quand le résultat dépend du moteur ou de l'expérience de jeu.
|
|
- Dans le compte rendu, nommer l'approche retenue, les alternatives réellement pertinentes, les versions et liens de documentation consultés, les vérifications effectuées et ce qui reste non vérifié. Distinguer une recommandation fondée sur la documentation d'un comportement observé en jeu.
|