Utiliser le SDK en JavaScript

Le SDK est écrit en TypeScript, mais il fonctionne exactement pareil en JavaScript pur — aucune étape de build, aucun outil supplémentaire nécessaire. Les types ne servent qu'à l'autocomplétion et à la vérification statique dans votre éditeur ; à l'exécution, tout est du JavaScript standard (le build publié CJS/ESM ne contient plus aucune annotation de type, elles sont retirées à la compilation du package lui-même).

Sur chaque page de cette documentation, les blocs de code proposent un onglet JavaScript à côté de TypeScript — cliquez pour voir l'équivalent exact.

CommonJS (require) — le plus courant pour un bot Node classique

const { BloumeChat, EmbedBuilder, PermissionFlags } = require("bloumechat");

const client = new BloumeChat();

client.on("ready", () => {
  console.log(`Connecté en tant que ${client.user?.tagString}`);
});

client.on("messageCreate", async (message) => {
  if (message.content === "!ping") {
    await message.reply("🏓 Pong !");
  }
});

client.login(process.env.BOT_TOKEN);

Lancez-le directement, sans compilation :

node index.js

Ce mode fonctionne dans n'importe quel projet Node, y compris un package.json sans "type": "module" (le cas par défaut). Le SDK résout require("bloumechat") vers dist/index.js (champ main du package.json du package), qui est un build CommonJS.

ESM (import) — si votre projet utilise "type": "module"

import { BloumeChat, EmbedBuilder, PermissionFlags } from "bloumechat";

const client = new BloumeChat();

client.on("ready", () => {
  console.log(`Connecté en tant que ${client.user?.tagString}`);
});

client.login(process.env.BOT_TOKEN);

Ajoutez "type": "module" dans votre package.json pour activer la syntaxe import/export sans transpilation :

{
  "type": "module",
  "dependencies": {
    "bloumechat": "^4.2.0"
  }
}

Avec "type": "module", Node résout import ... from "bloumechat" vers dist/index.mjs (champ module), le build ESM natif du package — les deux formats exposent exactement la même API publique, seul le mécanisme de chargement diffère.

Mélanger CommonJS et ESM dans le même projet

Si une partie de votre code utilise require() (par exemple un plugin tiers en CJS) et une autre import, Node.js gère l'interopérabilité automatiquement pour bloumechat grâce à la double publication CJS/ESM — vous n'avez rien à configurer de plus que le "type" du fichier ou du dossier concerné.

Ce qui change entre les exemples TypeScript et JavaScript de cette doc

Concrètement, quasiment rien. Les seules différences sont :

TypeScript	JavaScript	Pourquoi
import { BloumeChat } from "bloumechat";	const { BloumeChat } = require("bloumechat"); (CJS) ou identique en ESM	Le SDK publie à la fois un build CJS et ESM (main/module dans son package.json) — les deux fonctionnent.
process.env.BOT_TOKEN!	process.env.BOT_TOKEN	Le ! est un "non-null assertion" — une annotation TypeScript pure, ignorée à l'exécution. Sans TypeScript, on l'enlève simplement (le SDK valide de toute façon que le token est une chaîne non vide au runtime, avec ou sans !).
client.on("messageCreate", (message: Message) => {...})	client.on("messageCreate", (message) => {...})	Les annotations de type sur les paramètres n'existent qu'en TypeScript — en JS, message reste un objet Message identique à l'exécution, juste sans vérification statique.
interface ActivityData { ... }	(rien — non applicable)	Les interface/type sont purement compile-time, elles n'ont pas d'équivalent JS car elles ne génèrent aucun code. Le SDK accepte quand même un objet JS respectant la même forme ({ type, name, ... }).
member.hasPermission(permission: bigint)	member.hasPermission(permission)	Le paramètre reste un littéral BigInt standard ES2020 (1n) des deux côtés — voir Permissions.

Aucune perte de fonctionnalité

Rien dans le SDK n'est réservé à TypeScript — le typage n'est qu'une couche d'aide au développement (autocomplétion, détection d'erreurs avant l'exécution). Toute méthode, tout event, toute classe documentée dans cette doc fonctionne à l'identique en JavaScript pur.

Autocomplétion en JavaScript (sans TypeScript)

Même sans écrire de TypeScript, VS Code (et la plupart des éditeurs modernes) lit les fichiers .d.ts publiés avec le package et vous donne l'autocomplétion et la documentation au survol directement en .js — grâce à // @ts-check (optionnel) ou nativement via le serveur de langage TypeScript intégré à VS Code, activé automatiquement pour les fichiers .js d'un projet qui a bloumechat en dépendance.

const client = new BloumeChat();
client. // ← l'autocomplétion liste ici toutes les méthodes, même en .js

Ceci fonctionne aussi pour les objets retournés par le SDK : message. affichera content, author, channel, reply(), etc. avec leur documentation JSDoc extraite directement du code source.

JSDoc — typer votre propre code JS sans TypeScript

Si vous voulez garder les bénéfices du typage dans votre propre bot sans passer à .ts, des commentaires JSDoc suffisent :

/**
 * @param {import("bloumechat").Message} message
 */
async function handlePing(message) {
  if (message.content === "!ping") {
    await message.reply("🏓 Pong !");
  }
}

Cette technique fonctionne pour n'importe quel type exporté par le package — Guild, Member, Role, EmbedBuilder, les interfaces comme ActivityData, etc. :

/**
 * @param {import("bloumechat").ActivityData} activity
 */
function describeActivity(activity) {
  return `${activity.type}: ${activity.name}`;
}

Pour activer la vérification stricte des types dans un fichier .js (l'éditeur signale les erreurs de type comme dans un .ts), ajoutez // @ts-check en première ligne du fichier :

// @ts-check
const { BloumeChat } = require("bloumechat");

const client = new BloumeChat();
client.setActivity({ type: "playing", nam: "typo détectée par @ts-check" });
//                                     ^^^ signalé comme propriété inconnue

Prochaine étape

Poursuivez avec la liste complète des Événements — chaque event y est documenté avec son onglet JavaScript, exactement comme sur cette page.