Skip to content

Update CHANGELOG.md #37

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
AureDulvresse merged 1 commit into from
Oct 6, 2026
Merged

Update CHANGELOG.md #37

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
2 changes: 2 additions & 0 deletions CHANGELOG.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -20,6 +20,8 @@ Les versions `0.1.x`/`0.2.0` (juin 2026) correspondent à la phase de prototypag
- `Support\ServiceIntegration` — classe de base pour représenter un service externe comme une unique classe liée au conteneur : lit son propre bloc `config('services.<key>')`, expose un `HttpClient` pré-configuré (`base_uri` + jeton `Bearer`) via `http()`, et vérifie ses propres webhooks via `verifyWebhook()` — qui lit, comme le middleware `webhook`, `webhook_header`/`webhook_timestamped`/`webhook_tolerance` depuis la config (un appel sans argument suffit ; les paramètres ne servent qu'à surcharger ponctuellement). Ne remplace pas le mécanisme de binding existant (`#[Module(providers: [...])]`) — comble l'absence de convention sur *la forme* d'un service externe une fois lié.
- `config/services.php` (skeleton) documente désormais cette convention (`base_uri`, `secret`, `webhook_secret`, ...) dans son exemple commenté.

## [2.4.1] - 2026-10-02

### Changed

- **`fakerphp/faker` et `psy/psysh` déplacés vers `require-dev`** — tous deux ne sont utilisés qu'en développement (`Database\Factory::fake()`/`db:seed` pour le premier, la commande REPL `tinker` pour le second), jamais au boot ni dans une requête HTTP. Une installation `composer install --no-dev` (prod) n'embarque donc plus ni l'un ni l'autre. `tinker` continue de se dégrader proprement si `psy/psysh` manque (`Console\Kernel::registerFrameworkCommands()` enveloppe déjà chaque commande dans un `try/catch`) ; `db:seed` dispose maintenant de son propre `try/catch` dédié (voir ci-dessous) puisque, contrairement à `tinker`, l'échec ne peut survenir qu'à l'exécution du seeder, pas à l'enregistrement de la commande. Une application qui a besoin de l'un ou l'autre en local/CI doit désormais les redéclarer dans son propre `require-dev` — c'est fait pour le skeleton.
Expand Down
Loading