Passer au contenu principal
Les hooks d’installation sont des fonctions logiques spéciales qui s’exécutent pendant le cycle de vie d’installation ou de mise à niveau. Ils partagent le même environnement d’exécution que les fonctions logiques classiques et reçoivent un InstallPayload ({ previousVersion?: string; newVersion: string }previousVersion est undefined lors d’une nouvelle installation), mais ils sont déclarés avec leurs propres fonctions de définition et ne relèvent pas du modèle de déclencheur habituel (HTTP, cron, événements de base de données). Chaque application peut définir au maximum une pré-installation et au maximum une post-installation. La génération du manifeste renvoie une erreur si plus d’une fonction de l’un ou l’autre type est détectée.

En un coup d’œil

Règle empirique : privilégiez post-install par défaut. Ne recourez à la pré-installation que lorsque la migration elle-même est destructive et que vous devez intercepter l’état précédent avant qu’il ne disparaisse.

Comportement partagé par les deux hooks

  • La configuration est une configuration defineLogicFunction moins les paramètres de déclencheur, plus shouldRunOnVersionUpgrade.
  • Quand il s’exécute : uniquement lors des nouvelles installations, par défaut. Définissez shouldRunOnVersionUpgrade: true pour qu’il s’exécute également lors des mises à niveau. Utilisez previousVersion / newVersion pour bifurquer selon le chemin de mise à niveau.
  • L’idempotence est importante : le post-install asynchrone peut être relancé, et chaque hook est réexécuté lors des mises à niveau lorsque shouldRunOnVersionUpgrade est activé.
  • L’environnement habituel des fonctions logiques (APPLICATION_ID, APP_ACCESS_TOKEN, API_URL) est injecté, ce qui vous permet d’appeler l’API Twenty avec le jeton de votre application.
  • Le hook est rattaché automatiquement au manifeste de l’application au moment de la compilation (preInstallLogicFunction / postInstallLogicFunction) — rien à référencer dans defineApplication().
  • La valeur par défaut de timeoutSeconds est 300 pour permettre des tâches de configuration plus longues comme l’initialisation des données.
  • Non exécuté en mode dev : yarn twenty dev ignore le flux d’installation et synchronise directement les fichiers, donc les hooks ne s’exécutent jamais dans ce cas. Déclenchez-les manuellement à la place :
S’exécute une fois que votre application a terminé son installation : métadonnées synchronisées, client SDK généré, nouveau schéma interrogeable. Exemple — initialiser un enregistrement par défaut lors des nouvelles installations :
src/logic-functions/post-install.ts
Le drapeau shouldRunSynchronously contrôle le modèle d’exécution :
  • false (par défaut) — mis en file d’attente dans la file de messages (retryLimit: 3) et exécuté par un worker. La réponse d’installation est renvoyée dès que la tâche est mise en file d’attente. À utiliser pour les travaux de longue durée — initialisation de grands ensembles de données, API tierces lentes.
  • true — exécuté en ligne pendant le flux d’installation. La requête d’installation est bloquée jusqu’à ce que le gestionnaire ait terminé ; une erreur levée apparaît comme POST_INSTALL_ERROR pour l’appelant (aucune nouvelle tentative). À utiliser pour les travaux rapides qui doivent être terminés avant la réponse. La migration a déjà été appliquée à ce stade, donc un échec n’annule pas les modifications du schéma — il ne fait que remonter l’erreur.
S’exécute avant la migration des métadonnées, sur le schéma précédent — l’endroit idéal pour sauvegarder des données qu’une migration ferait perdre, ou pour refuser une mise à niveau risquée. Avant l’exécution, le serveur effectue une « synchronisation réduite » purement additive qui enregistre uniquement la fonction de pré-installation de la nouvelle version ; tout le reste — les objets, champs et données de la version précédente — reste intact lorsque votre gestionnaire s’exécute.La pré-installation est toujours synchrone et bloque l’installation. Si le gestionnaire lève une exception, l’installation est abandonnée avant toute modification du schéma — l’espace de travail reste sur la version précédente dans un état cohérent. C’est intentionnel : la pré-installation est votre dernière chance de refuser une mise à niveau risquée.Exemple — copier les valeurs d’un champ hérité avant que la migration ne le supprime :
src/logic-functions/pre-install.ts