Règles d'indépendance

Les préfixes de table, le comportement à la désinstallation, les modules enfants et les états de compatibilité, en détail.

Le kernel les impose. Elles existent pour qu'un acheteur puisse installer, désactiver et supprimer n'importe quel module sans jamais mettre le core en danger.

1. Vos tables, et seulement vos tables#

Chaque table que créent vos migrations est préfixée mod_<slug>_, les tirets devenant des tirets bas. Pour un module au slug members-plus, cela donne mod_membersplus_ ou mod_members_plus_ selon le slug que vous avez choisi, et c'est vérifié au moment de l'installation.

Lire les données du core est permis. Les écritures structurelles en dehors de votre préfixe ne le sont pas, et un paquet dont les migrations sortent de ce périmètre est refusé.

2. La désinstallation retire votre module et rien d'autre#

onUninstall(bool $purge) supprime vos tables et efface vos enregistrements de migration. Le core n'est pas touché, donc une réinstallation repart de zéro.

Désactiver est l'opération réversible : rien n'est supprimé et le module revient exactement comme il était. Assurez-vous que onDisable() ne fait aucun nettoyage que onEnable() ne peut pas annuler.

3. Aucune clé étrangère entre modules#

Ne pointez jamais une clé étrangère vers la table d'un autre module. Ce module peut être désinstallé pendant que le vôtre tourne, et une contrainte pendante ferait tomber tout le site.

Utilisez plutôt une référence polymorphique avec un alias en chaîne, et résolvez-la via un guard.

4. Vos propres fichiers de langue#

Code

modules/<slug>/resources/lang/en/<file>.php

Chargés sous un namespace et référencés sous la forme slug::file.key. Rien de ce qui est à vous ne va dans les fichiers de langue du core, et chaque chaîne est rédigée en anglais.

5. L'échec est isolé#

Le boot est résilient : un module qui lève une exception est ignoré et la requête continue. Ne comptez pas là-dessus comme gestion d'erreurs, mais comptez dessus pour la garantie qu'elle donne à vos acheteurs.

6. Modules enfants#

parent: "<slug>" déclare que votre module étend un autre module plutôt que le core.

Un enfant exige que son parent soit installé et activé.
Désactiver le parent désactive ses enfants en cascade.
Désinstaller un parent est bloqué tant qu'un enfant est installé.
Les enfants sont listés en retrait sous leur parent dans le panneau.

Les passerelles de paiement en sont l'exemple canonique : chacune est un enfant de payments et n'enregistre son driver que tant que le parent est actif.

7. États de compatibilité#

État	Déclencheur	Effet
À jour	`tested_up_to` est égal ou supérieur au core en cours d'exécution	Normal
Obsolète	`tested_up_to` est inférieur au core en cours d'exécution	Avis orange, continue de fonctionner
Incompatible	Une entrée `requires` n'est plus satisfaite	Désactivé au boot, ne peut pas être activé avant une mise à jour

Gardez tested_up_to honnête. C'est ce qui indique à un acheteur s'il faut s'attendre à des problèmes.

8. Vos propres réglages#

Un module peut avoir ses propres pages de réglages, indépendantes de celles du core. Déclarez le nom de la route dans settings dans le manifeste, et la liste des modules affiche le raccourci tant que le module est activé.

Liste de vérification#

Tables préfixées et supprimées à la désinstallation.
Aucune clé étrangère vers un autre module.
Chaque chaîne dans vos propres fichiers de langue, rédigée en anglais.
Chaque appel inter-modules derrière class_exists ou Route::has.
Assets compilés dans le paquet, aucun build sur l'hébergement de l'acheteur.
Aucun script inline nulle part.