Migrating from DJS-Commander

If you're trying to use CommandKit as a drop-in replacement for DJS-Commander, you'll need to make a few changes to your code.

warning

This guide is not introducing the features this library offers over DJS-Commander. It's just going over the changes you'll need to make to your code to get it working with this library.

Setting up the command handler

In DJS-Commander, you'd import and instantiate the CommandHandler class. The only difference with CommandKit is the name of the class. Instead of CommandHandler, it's called CommandKit.

const { CommandKit } = require('commandkit');

new CommandKit({
  client,
  commandsPath,
  eventsPath,
});

Setting up development servers

In DJS-Commander only a single development server was supported, and it was setup under the property name testServer when instantiating CommandHandler.

new CommandHandler({
  client,
  commandsPath,
  eventsPath,
  testServer: '123456789012345678', // ❌
});

In CommandKit, you can setup multiple development servers under the property name devGuildIds

new CommandKit({
  client,
  commandsPath,
  eventsPath,
  devGuildIds: ['123456789012345678', '876543210987654321'], // ✅
});

However, this does not automatically register all the commands in those specific servers. By default, CommandKit will globally register all commands. If you want to register commands in specific servers, you'll need to use the devOnly property inside options from within the command file object.

module.exports = {
  data: {
    name: 'ping',
    description: 'Pong!',
  },

  run: ({ interaction }) => {
    interaction.reply('Pong!');
  },

  options: {
    devOnly: true, // ✅
  },
};

This command will now be registered in your development server, however you won't be able to run this command as you haven't configure the developer user IDs. Yes, CommandKit has built in support for developer user IDs! You can set them up under the property name devUserIds when instantiating CommandKit.

new CommandKit({
  client,
  commandsPath,
  eventsPath,
  devGuildIds: ['123456789012345678', '876543210987654321'],
  devUserIds: ['123456789012345678', '876543210987654321'], // ✅
});

Deleting commands

Deleting commands with CommandKit is a bit different from DJS-Commander's. In DJS-Commander you'd directly export the deleted property from the command object. In CommandKit, you're required to export the deleted property inside another object called options.

module.exports = {
  data: {
    name: 'ping',
    description: 'Pong!',
  },

  run: ({ interaction }) => {
    interaction.reply('Pong!');
  },

  deleted: true, // ❌

  options: {
    deleted: true, // ✅
  },
};

Updating validations parameters

In DJS-Commander, you'd get access to the interaction and commandObj in a specified order through the parameters. In CommandKit, you get access to the interaction and commandObj through an object.

// DJS-Commander
module.exports = (interaction, commandObj) => {}; // ❌

// CommandKit
module.exports = ({ interaction, commandObj }) => {}; // ✅