Laravel API Generator

Français

English

Français

English

Apparence

Faire évoluer les entités ​

Les générateurs sont formidables au jour 1 et inutiles au jour 30 quand régénérer efface vos modifications manuelles. Ici, régénérer laisse de côté les fichiers que vous avez modifiés, et --add-fields patche les entités à enrichir.

Ajouter des champs à une entité existante ​

bash
php artisan make:fullapi Post --add-fields="excerpt:text,status:enum(draft,published)"
php artisan migrate

Ce qui se passe :

  • Une migration incrémentale Schema::table() est créée (avec un vrai down())
  • Les colonnes fillable ($fillable ou #[Fillable]), les casts (casts(), ou $casts dans un modèle écrit par la 3.x) et le bloc PHPDoc du modèle existant sont patchés en place
  • Les règles de validation vont dans les deux requests (avec sometimes dans celle de mise à jour), les valeurs de factory et les champs de resource à leur place
  • La classe enum est générée si nécessaire
  • Les champs déjà existants sont ignorés ; vos méthodes personnalisées ne sont jamais touchées

Le DTO (promotion de constructeur) et les tests générés sont volontairement laissés de côté et signalés comme suivis manuels.

Vos modifications survivent à la régénération ​

Le générateur note ce qu'il écrit dans .api-generator/manifest.json. Committez ce fichier. Au passage suivant, tout fichier généré que vous avez modifié à la main reste tel quel, et le rapport le nomme :

  kept      app/Models/Post.php
  ! app/Models/Post.php was edited since it was generated, so it was kept. Use --force to overwrite it.

Les fichiers que vous n'avez pas touchés sont rafraîchis comme d'habitude. Ajoutez --force pour écraser aussi les fichiers modifiés, ou prévisualisez tout le passage avec --dry-run. Les entités générées avant la 3.11 sont régénérées comme avant lors de leur prochain passage, puis suivies.

Régénérer des fichiers précis ​

Changé d'avis sur un seul artefact ? --only= réécrit uniquement les générateurs listés et laisse la migration, la route et l'enregistrement du seeder intacts. Le manifeste garde aussi la définition à partir de laquelle chaque entité a été générée, il n'y a donc rien à retaper :

bash
php artisan make:fullapi Post --only=Resource
php artisan make:fullapi Post --only=FeatureTest,UnitTest

Les relations, les valeurs d'enum, les clés étrangères, les colonnes unique et nullable et les options de génération reviennent telles quelles, comme les champs ajoutés avec --add-fields. Leurs colonnes restent dans leur propre migration.

Une entité générée avant la 4.1 n'a pas encore de définition enregistrée, la commande demande donc ses champs. Passez-les une fois, ou régénérez l'entité depuis son fichier de schéma, sa base ou son diagramme, et la définition est enregistrée à partir de là :

bash
php artisan make:fullapi Post --fields="title:string,content:text" --only=Resource

Types disponibles : Model, Controller, Service, DTO, Request, Resource, Migration, Factory, Seeder, Policy, FeatureTest, UnitTest.

Supprimer proprement ​

bash
php artisan delete:fullapi Post

Supprime chaque fichier généré, désenregistre le seeder de DatabaseSeeder.php, et retire les routes de l'entité de routes/api.php et routes/web.php. Les migrations ajoutées avec --add-fields partent aussi, puisque le manifest les connaît. Ajoutez --dry-run pour voir la liste d'abord ; la confirmation nomme aussi les fichiers modifiés à la main. Les enums et les migrations pivot restent, car d'autres entités peuvent s'en servir.

Réparer les routes orphelines ​

Si un fichier de routes référence encore un contrôleur supprimé (la fameuse ReflectionException de route:list), purgez les lignes orphelines :

bash
php artisan api-generator:clean-routes --dry-run
bash
php artisan api-generator:clean-routes

L'extension VS Code propose cette réparation quand sa liste des routes échoue sur un contrôleur orphelin.