Passer au contenu principal
chapterjs dev fait tourner le bot du dossier courant sur votre serveur de test, et recharge vos fichiers quand vous les enregistrez. C’est ce que lance le script dev de votre projet :
C’est tout : le bot est en ligne sur votre serveur de test, vos commandes y apparaissent, et chaque fichier de src/ est surveillé. Tout ce dont la commande a besoin de Discord est déduit de vos fichiers : les intents de la deuxième ligne, ce dont le bot se souvient, les commandes à enregistrer.
Les options, les variables d’environnement et les codes de sortie de la commande sont dans la référence du CLI.

Ce dont elle a besoin

Un fichier .env à la racine de votre projet, avec deux valeurs :
.env
Où les trouver est dans Votre application Discord. Une valeur réglée dans le vrai environnement l’emporte sur le fichier.
BOT_TOKEN est le token d’une application de dev, pas du bot qui est en ligne pour tout le monde. Nous recommandons deux applications dès le départ : un bot pour votre ordinateur, un bot pour la production. Avec un seul bot pour les deux, votre serveur de test affiche en double chaque commande que vous modifiez, et la présence, les intents privilégiés et le token de production sont partagés avec ce que vous essayez. Comment la mettre en place : Un second bot pour le développement.
Sans le fichier, la commande s’arrête avant toute autre chose :
Et elle doit tourner dans le dossier de votre bot, celui qui contient package.json et src/ :

Ce qu’elle vérifie pour vous

Avant de se connecter, chapterjs dev s’assure que tout est en place. Quand quelque chose manque, elle dit quoi et comment le corriger, et quand vous êtes dans un terminal, elle attend la correction au lieu de vous faire tout recommencer :
Chaque problème est affiché d’un coup : une valeur vide, encore la valeur d’exemple, un token avec un espace dedans, un identifiant de serveur qui n’est pas fait de chiffres. La commande s’arrête ; corrigez .env et relancez-la.
Discord ne reconnaît pas le token, généralement parce qu’il a été réinitialisé. La commande s’arrête.
Vous recevez un lien qui ajoute le bot à ce serveur, avec toutes les permissions : un serveur de test est un terrain de jeu. Ouvrez-le, confirmez, et la commande continue toute seule.
Certains événements ont besoin d’une option activée pour votre bot dans le Developer Portal. Vous recevez les fichiers qui en ont besoin et le lien vers la bonne page. Activez-la, enregistrez, et la commande continue toute seule.
Les trois options et les fichiers qui en ont besoin sont dans Votre application Discord.
La commande n’attend que lorsqu’elle tourne dans un terminal. Lancée par un autre programme, les deux mêmes messages sont des erreurs (✗) et la commande s’arrête avec le code de sortie 1.

Rechargement à l’enregistrement

Enregistrez un fichier et votre bot utilise la nouvelle version, sans se déconnecter :
Chaque fichier de src/ est surveillé : vos commandes, vos événements et les fichiers qu’ils importent. Un nouveau fichier ou un nouveau dossier est pris en compte dès qu’il est enregistré, et plusieurs fichiers enregistrés d’un coup font un seul rechargement. Un fichier enregistré pendant le démarrage de la commande n’est pas perdu : il est rechargé juste après. Un fichier avec une erreur n’arrête jamais votre bot. L’erreur est affichée avec le fichier et la ligne, et la dernière version qui fonctionnait continue de tourner jusqu’à ce que vous la corrigiez :
Avec plusieurs fichiers cassés, le message les compte : ⚠ Reloaded with 2 errors: those files keep running their last working version. Un fichier qui n’a jamais fonctionné est mis de côté jusqu’à ce qu’il fonctionne.
Recharger relance vos fichiers depuis zéro : une variable gardée dans un fichier (un compteur, une liste…) revient à sa première valeur à chaque enregistrement. Les paquets de node_modules ne sont pas rechargés.

Quand vos fichiers ont besoin de plus de Discord

Les intents sont donnés à Discord à la connexion du bot. Quand un fichier que vous enregistrez a besoin d’un intent que la connexion n’a pas (un nouvel événement, un fichier qui écoute maintenant les messages privés), le bot se reconnecte tout seul :
Si cet intent est privilégié et pas encore activé, vous recevez le même message et la même attente qu’avant la connexion. L’événement ready tourne une fois par démarrage, pas quand le bot se reconnecte.

Vos commandes sur votre serveur de test

Vos commandes sont enregistrées sur votre serveur de test uniquement, où elles apparaissent immédiatement. Discord n’est prévenu à nouveau que quand quelque chose que les gens voient a changé (un nom, une description, une option, une traduction) : changer ce que fait une commande ne coûte aucune requête, et relancer le bot non plus.
Lors d’un rechargement, la ligne est ↻ Commands updated on My Server. Quand Discord refuse ce que déclarent vos fichiers, le bot continue de tourner avec les commandes que Discord a déjà :
Une commande que la production affiche déjà pour tout le monde, exactement comme votre fichier la déclare, n’est pas ajoutée une seconde fois. Pendant que vous en modifiez une, votre serveur de test l’affiche en double et la commande vous le dit une fois :
Une application de dev n’affiche jamais cela : voir Un second bot pour le développement.

Seulement votre serveur de test

En dev, votre bot ne voit que le serveur de DEV_GUILD_ID. Ce qui se passe dans les autres serveurs où il se trouve, et en messages privés, est ignoré, et les intents qui ne servent qu’aux messages privés ne sont pas demandés. C’est le rôle de chapterjs start, qui peut faire tourner le même bot pour tout le monde en même temps. Ce qui ne fonctionne qu’en messages privés ne peut pas être essayé en dev, et chapterjs dev nomme le fichier une fois :

Les types de votre projet

Au démarrage, chapterjs dev écrit les types de votre projet dans le dossier .chapterjs/ : ce que votre projet ajoute aux types de chapterjs, les fichiers de public/ que propose asset(), vos langues, qui typent t, et vos commandes. Le dossier est ignoré par git et supprimable. chapterjs sync les écrit sans lancer le bot. Les projets créés avec create chapterjs le lancent après chaque installation, pour que votre éditeur connaisse les types tout de suite. Pour vérifier les types de tout votre projet depuis un terminal, utilisez le script typecheck de votre projet :
Il lance tsc -b. Un simple tsc ne vérifie rien dans un projet ChapterJS : vos fichiers sont vérifiés par les projets de .chapterjs/, que seuls tsc -b et votre éditeur suivent.

Pendant que le bot tourne

La connexion à Discord est gardée en vie par le framework. Quand elle tombe, le bot se reconnecte tout seul et vos fichiers continuent de tourner :
Une erreur dans une de vos fonctions est affichée avec le fichier et la ligne, et n’arrête rien d’autre : voir quand votre fonction échoue. Le bot s’occupe aussi de sa propre mémoire : voir Mémoire.

Une nouvelle version de ChapterJS

Une fois le bot en ligne, chapterjs dev vous prévient quand une version plus récente du paquet est sortie, avec la commande qui l’installe, écrite pour le gestionnaire de paquets de votre projet :
npm est interrogé au plus une fois par jour, après la mise en ligne du bot, et ne le retient jamais : sans internet, la ligne n’apparaît pas. Rien n’est installé à votre place : lancez la commande quand vous voulez, puis relancez chapterjs dev.

Arrêter

Appuyez sur Ctrl+C. Le bot se déconnecte proprement et passe hors ligne immédiatement :
Un second Ctrl+C, une seconde plus tard, arrête le processus sans attendre ; Discord affiche alors le bot en ligne jusqu’à ce qu’il remarque que la connexion a disparu.

chapterjs build

Vérifier votre bot et le compiler pour la production.

Dépannage

Chaque message, et quoi en faire.