Packages et configuration de l'intégration
Tous les projets ne doivent pas être livrés sous forme de plugin d'exécution exécutable.
Parfois, la véritable exigence est un package qu'un autre système chargera, un artefact d'extension ou une configuration d'intégration enregistrée qui réside dans le dépôt.
La règle courte
Choisissez des packages ou une configuration d'intégration lorsque la forme de livraison compte plus que l'exécution directe du plugin.
Choisissez cette page quand
C'est la bonne voie lorsque :
- l'emballage est la véritable exigence de livraison
- l'hôte attend une extension ou un artefact packagé
- le dépôt a principalement besoin d'une configuration d'intégration enregistrée pour un autre outil
- un runtime exécutable ajouterait du travail opérationnel inutile
Qu'est-ce qui différencie cela d'un chemin d'exécution
Un chemin d'exécution est généralement la valeur par défaut la plus claire lorsque vous souhaitez un plugin exécutable.
Les packages et la configuration de l'intégration répondent à une question différente : comment ce plugin doit-il être livré ou connecté à un autre système ?
Le modèle mental sûr
Choisissez le runtime lorsque vous souhaitez exécuter le plugin directement. Choisissez des packages ou une configuration d'intégration lorsque la forme de la livraison est la principale exigence.
Codex Limite du colis
Pour le package officiel Codex, gardez la disposition du bundle explicite et étroite :
.codex-plugin/contient uniquementplugin.json- facultatif
.app.jsonet.mcp.jsonrestent à la racine du plugin
Ce chemin de package est destiné à la surface officielle du bundle de plugins Codex, et non à mélanger le câblage du runtime du référentiel local dans la présentation du package.