In usage, if I was todo <Command:somerandomthing> and run the command console would get spammed with unknown argument type and spam till getting a Javascript stack trace (infinite loop) https://github.com/dirigeants/klasa/blob/master/src/lib/structures/CommandMessage.js#L138 basically what happening is this.client.emit('warn', 'Unknown Argument Type encountered'); return this.multiPossibles(++possible, validated); here it emits warn event then runs the multiPossibles function again causing an infinite loop

well oops basically https://i.imgur.com/ravkASt.png

when i go to edit a cmd and do the 1st optional argument prompts when it shouldn't

What I mean

in usage strings, you can currently only have optional or required flags in usage but what I mean is having a string in a usage like <reminder:string> in <Time:time> so the command format would be prefix remind me to bug ao about this proposal in 1 hour just like Skyra's reminder command

Examples

usage: "<reminder:string> in <time:time>"

Behaviour

The command to throw some string if in the literal string isn't there this could also be wrapped in <in> or [in] making it required or optional

Version 10 of Node.js (code name Dubnium) has been released! 🎊

To see what happens to your code in Node.js 10, Greenkeeper has created a branch with the following changes:

• Added the new Node.js version to your .travis.yml
• The new Node.js version is in-range for the engines in 1 of your package.json files, so that was left alone

If you’re interested in upgrading this repo to Node.js 10, you can open a PR with these changes. Please note that this issue is just intended as a friendly reminder and the PR as a possible starting point for getting your code running on Node.js 10.

Your Greenkeeper Bot 🌴

An increment method for SG to add/remove numbers from SG Configs.:

// Increment by 1
this.client.configs.increment('commandsUsed', 1);
// Decrement by 1
this.client.configs.increment('commandsUsed', -1);

Current Method of doing this:

// Increment by 1
this.client.configs.update('commandsUsed', this.client.configs.commandsUsed + 1);
// Decrement by 1
this.client.configs.update('commandsUsed', this.client.configs.commandsUsed - 1);

Databases have built-in methods for incrementing which might help in implementing this in providers. MongoDB
RethinkDB

Benefits: Shorter and simpler. Perhaps faster?
Use cases: experience systems, analytics and counters.

Describe the issue

When Duration#toNow is used on Date objects or timestamps earlier than Date.now(), it returns seconds always.

Code or steps to reproduce

1. Put a timestamp higher than Date.now() on the first parameter of Duration#toNow()

Expected an actual behaviour

Return the actual Duration, returned seconds instead.

Further details

• discord.js version: master branch; commit: 745669a
• node.js version: 10.0.0
• Klasa version: master branch; commit: f58681d
• I have modified core files.
• I have tested the issue on latest master. Commit hash:

Version 9.4.0 of @types/node was just published.

This version is covered by your current version range and after updating it in your project the build failed.

@types/node is a devDependency of this project. It might not break your production code or affect downstream projects, but probably breaks your build or test tools, which may prevent deploying or publishing.

Your Greenkeeper Bot 🌴

Describe the issue

When KlasaClientOptions.cmdEditing is set to true and command prompt are enabled (formerly known as KlasaClientOptions.cmdPrompt before the refactor), Klasa identifies message edits as new messages, therefore, prompts will identify command edits as the response (which is unwanted most of the time).

Proposal: To fix this issue, we should check if the message received is the same as the one that triggered the prompt. In that case, return an invalid value (i.e. null). As throwing will be (in most cases) identified as the lack of a response. This will be handled by the developer (a notice should be made in the documentation via the JSDoc).

If the message is edited during Usage's prompt, Klasa should cancel the current command execution and re-parse it. That way, when you do:

s!conf set prefix

You'll be prompted by Usage asking for the value to set. And then you edit it to:

s!conf set prefix m!

That'll identify s!conf set prefix m! as the accepted value, in this case, making that the new prefix (in practice this will error as there's a maximum number of characters in the schema) and will run the same command but with m! as the value. This is pretty dangerous in some cases as, related to #180, ratelimits aren't applied during command parsing but after successful command run, so you could call the command multiple times with the prompt and edit them later, causing a fatal issue.

To counter this issue, I propose prompt cancellation when the captured message in Message#prompt() is the same one as the message that called the prompt.

Further details

• discord.js version: master
• node.js version: 9.3.0
• Klasa version: 0.5.0-dev
• I have modified core files.
• I have tested the issue on latest master.

When using commands, they are case insensitive. When using the help command, however, you must use exact case for the command you want help on.

Where the prefix is +:

+Ping
(Works)

+Help Ping
(It can't find the command...not that it tells you that. It sends you the entire list of commands, but I digress)

I am proposing that the cmd ArgResolver be changed to allow this.

Hi,

I've just spotted a little missing parenthesis ')' into the UnderstandingPermissionLevel tutorial.

On the second example (the one showing how to override the defaultPermissionLevels).

Not sure if it's useful but I made a fix here:
#34

is there a client option that would let the owner set a custom amount of level above 10.

Describe the issue

Having SchemaPiece on a SchemaFolder breaks conf get when trying to access the folder, conf get SchemaFolder#SchemaPiece will work just as fine.

Code or steps to reproduce

1. Create a SchemaFolder
2. Create a SchemaPiece with type as TextChannel
3. Run conf get <SchemaFolder>

Expected an actual behaviour

• show the SchemaFolder with the piece properly

Further details

• discord.js version: discordjs/discord.js@4ab72af
• node.js version: v9.2.1
• Klasa version: db946cc
• I have modified core files.
• I have tested the issue on latest master. Commit hash: db946cc

The docs are still far from perfect, and we would like feedback from our developers to help us improving them before Klasa 1.0.0 release.

Between the issues we could notice:

• Some parts are not correctly clarified, causing confusions to our new developers.
• The learning curve isn't fully normalized and starting with Klasa is way very hard for many new developers. For the easiness we give, and with the consistency we keep with discord.js, this should not be an issue, but in the current state, it is, perhaps we need to show this to our users.
• Lack of use-cases of Klasa, "Building Your Bot" guides, etc. This affects user retention, and we would like to help them with better examples.
• Lack of examples, we have many many lines of code, whilst they are fully documented, they do not provide good examples.

Describe the issue

It isn't a huge breaking bug, but something I thought worth mentioning. Honestly, i am not even sure if this is something that can even be fixed.

Typings automatically begin saying BOTNAME is typing... however, it does not take into consideration where the bot is sending the message. For example, if someone runs a command in a channel the bot will say the typings BUT that command actually sends a message in another channel. Its confusing as it seems to cause users to think the bot has broke until they realize oh the message came here.

P.S. This is not breaking just something to make it less inconvenient in those rare circumstances.

Code or steps to reproduce

1) Enable Typings
2) Run a command that sends a message to different channel 

Expected an actual behaviour

Typings should occur on the channel where the bot types.

Further details

• discord.js version: latest
• node.js version: 9+
• Klasa version: latest
• I have modified core files.
• I have tested the issue on latest master. Commit hash:

By the time HactoberFest begins, RichDisplay and RichMenus should be merged into master. It would be great for someone to write tutorials for using them (like the other docs tutorials you can find in the ./tutorials folder).

The tutorials should include a general overview, basic implementation with explanation of parameters, and creative examples of use. The RichMenu should have it's own tutorial as a child of RichDisplay (RichMenu extends RichDisplay) highlighting the similarities and differences, and it's own examples of use.

Please be sure to create your pull request after the first of October so your pr counts for HactoberFest. More details about HactoberFest

Edit: The RichDisplay Tutorial has been completed, and merged. A RichMenu tutorial is still wanted.

Version 0.8.2 of markdownlint-cli was just published.

This version is covered by your current version range and after updating it in your project the build failed.

markdownlint-cli is a devDependency of this project. It might not break your production code or affect downstream projects, but probably breaks your build or test tools, which may prevent deploying or publishing.

Your Greenkeeper Bot 🌴

☝️ Greenkeeper’s updated Terms of Service will come into effect on April 6th, 2018.

Version 9.6.1 of @types/node was just published.

This version is covered by your current version range and after updating it in your project the build failed.

@types/node is a devDependency of this project. It might not break your production code or affect downstream projects, but probably breaks your build or test tools, which may prevent deploying or publishing.

Your Greenkeeper Bot 🌴

Describe the proposal

Currently, changing the colors for the KlasaConsole is, tedious. With code like this

new Client({
    console: {
        colors: {
            [event]: {
                time: {
                    background: "green",
                },
            },
        },
    },
});

looking quite bad.

This proposal is a way to either re-use the already existing Colors class, or another class, to be able to do something more like

new Client({
    console: {
        colors: {
            [event]: {
                time: new Colors({ background: "green", text: "white", style: "underline" }),
                message: new Colors({ background: "white", text: "black" }),
            },
        },
    },
});

This looks way cleaner, and more concise in my opinion., and doesn't go extremely deep in the client options. (something eslint will appreciate if you have the depth rule configured.)

In the given example, [event] is an actual event name, like log or warn

Describe the proposal

When you have many extendables, for different classes, I bet it gets pretty disorganized. You can prefix their filenames with the class name, e.g., userProfile.js, but then you have to explicitly specify the property/method name in each one.

I'm proposing that subfolders in the ./extendables/ folder be used as the appliesTo arg by default, so that users can then make the filename the name of the property/method, for simplicity and for better organization.

Rationale

Commands have categories, which are useful for file organization. I propose similar usefulness for extendables.

Code or steps to use

./extendables/User/profile.js:

const { Extendable } = require('klasa');

class MyExtendable extends Extendable {

    get extend() {
        // return whatever
    }

}

module.exports = MyExtendable;

A file that uses it:

msg.author.profile // etc.

Caveats

• You wouldn't be able to specify multiple classes to apply the extendable to
  • You can still explicitly use the appliesTo arg
  • How often do users use multiple classes in appliesTo, anyway?
• You could do something unintuitive, like have a file ./extendables/User/modLog.js, with appliesTo: ['Guild']
  • That's your problem, to be honest; you can already do unintuitive things
• Unlike command categories, extendable appliesTo can be set explicitly with an option; this makes for an inconsistency in Klasa
• For a class that one has a lot of extenders for, it probably makes more sense to make a class extending it and pass that to Discord.js directly, rather than using Klasa extendables

Describe the issue

Having a RichDisplay sent in a DM will cause havoc on your logs. The commands work perfectly. The rich display works perfectly. The pages change perfectly. It does everything that it should do but it keeps sending this error to your log for every reaction that clicked. So if a user clicks 2-3 times and you have thousands of users on a popular command it destroys logs.

There should be a way to catch/ignore this error somehow because as I said the command works perfectly. The users have no issues. But the developer logs are insanely spammed.

Uncaught Promise Error: 
DiscordAPIError: Cannot execute action on a DM channel
 at item.request.gen.end (node_modules/discord.js/src/rest/handlers/RequestHandler.js:79:65)
at then (node_modules/snekfetch/src/index.js:218:21)
 at <anonymous>
 at process._tickDomainCallback (internal/process/next_tick.js:228:7)

Code or steps to reproduce

1) Create a rich display command to run in a DM
2) Use reactions
3) Check logs

Expected an actual behaviour

Either a workaround or some sort of method to avoid this log is necessary. The only issue here is with the error log and not the RichDisplay or command. All i really need is a way to ignore this error from my console.

Further details

• discord.js version: latest
• node.js version: 9+
• Klasa version: latest
• I have modified core files.
• I have tested the issue on latest master. Commit hash:

When quotedStringSupport is set to true and a command uses a usageDelim that is not a space, commands with the repeator tag do not work correctly. (Tested with user type).

Expected Behaviour

Klasa would get all users and send an array of users.

Actual Behaviour

When I input one user, it works perfectly, but it fails with two or more.

Command input

> $test 383383927575937034, 242043489611808769
Error: person must be a mention or valid user id.
> $test "383383927575937034" "242043489611808769"
Error: person must be a mention or valid user id.
> $test "383383927575937034", "242043489611808769"
Error: person must be a mention or valid user id.

Code to reproduce

const { Command } = require('klasa');

module.exports = class extends Command {

	constructor(...args) {
		super(...args, { usage: '<person:user> [...]', usageDelim: ', ' });
	}

	run(msg, [...user]) {
		return msg.send(`Mentioned: ${user.map(us => us.tag).join(', ')}`);
	}

};

Extra details

When quotedStringSupport is set to false, it does parse the ids correctly.

Describe the issue

Code or steps to reproduce

Use the built-in help command on iOS

Expected an actual behavior* *Google is always right /s

Further details

• discord.js version: 12.0.0-dev
• node.js version: v9.8.0
• Klasa version: 0.5.0-dev
• I have modified core files.
• I have tested the issue on latest master. Commit hash:

To fix: Add newline before starting the codeblock
Additional: Remove blank newline at end of codeblocks

Describe the issue

Currently, we are using constructor to set up the config of a class.
Instead, we could use a method of the class. This will keep the code clean, simpler and more dynamic.

Code or steps to reproduce

class Parent {
  constructor(...args) {
    // Do something with it
    console.log(args)
  }
}

class Children extends Parent {
  constructor(...args) {
    super(...args, {
      command: "ping"
    })
  }
}

Expected an actual behaviour

class Children {
  constructor(...args) {
    let config;
    if (typeof this.config === "function") config = this.config();
    if (!config) throw Error("You forgot to set the config using the method config");
    
    // Do something with config or just make it available for the methods
    this._internalConfig = config;
  }
}

class TestChild extends Children {
  config() {
    return {"command": "ping"}
  }
}

Describe the proposal

At the moment we have absolutely no control about the order the inhibitors are run in. And for some ideas there is the scenario needed to run one inhibitor before another and to stop the the whole process
(to not run the other inhibitors following)

Describe the issue

With the fix of #147 it led to a new issue where the reaction needs to be tapped twice. I believe it occurs because now there is no way to remove the reaction automatically so you have to a) remove b) add new reaction.

EDIT: Oops sorry I wasn't saying the fix caused it just revealed that it needs 2. Even before the fix this issue occurred because the bot couldn't remove the reactions so they still had to click twice. This fix simply revealed this issue more to me.

Code or steps to reproduce

1) Create a richdisplay to run in DM
2) run the command and go to page 2
3) try to go to page 3 but it wont
4) click again and it will go to page 3

Expected an actual behaviour

The RichDisplay when it lacks perms to remove reactions could work when the user removes a reaction to move to next page

Further details

• discord.js version: latest
• node.js version: 9+
• Klasa version: latest
• I have modified core files.
• I have tested the issue on latest master. Commit hash:

Describe the proposal

With the PR #156 we have implemented Cron, however, we wanted to have a fully functional Cron before pulishing it and implement the rest of features. Currently, we're missing five non-standard wildcards:

Edit: Added Done column to the wildcard table and a list of commits implementing the new wildcards.

From the Wikipedia page.

We also support nonstandard predefined scheduling definitions, however, @yearly is supported where @annually isn't. (✅).

Implementation

• [4b4a42ad0f] Fixed the wildcard ?. (bdistin)
• [692e485d2b] Implemented the wildcards ?, H, and the scheduling definition @annually. (bdistin)

Further details

• Cron, Wikipedia
• Working with Cron, AWS
• Cheatsheet

Describe the proposal

The implementation of Command#cooldown is very effective, and it got enhanced thanks to Command#bucket allowed developers to have a better control of them without annoyingly set ratelimits at first command usage and disturb the user.

However, the underlying system feels incomplete and not very performant.

• It uses a timeout for every single cooldown, this is separated in multiple commands, so both RAM and CPU usage seems to be affected by this. In practice, the excessive amount of timeouts seems to make other shift even a bit. This could be fixed with a cooldown sweeper using an interval, similar to Schedule's system.

• It's not very effective: if a user spams a command, they should be notified only once, however, Klasa will reply as many times as it can. Some developers (me, included) use ratelimits to protect the bot from, not only heavy processing or limit the usage of commands, but also to protect the bot against breaking Discord ratelimits. That is, due to the lack of silent ratelimits.

Finally, there's an extreme side case that has been affecting my bot today: it's cool to put the ratelimits after a successful command run, however, there are commands (such the ones that send files or generates images) that take a while longer. These commands take more to resolve, therefore, they also take longer to fire the finalizers that put the user in cooldown. For example, I have a command that takes ~1 second to process an image and send it to Discord, the command has a cooldown of 30 seconds with a bucket of 1. A user sends 5 messages within that second.

Expected behavior: Run one, ratelimit the second, ignore the other three (with this proposal).
Actual behavior: As cooldowns aren't applied until the first successful command run, the bot does run all 5 commands.

Implementation

• Cooldown Sweeper: Not implemented yet.
• Silent Cooldown: Not implemented yet.

Describe the issue

Error when trying to update a SG config of type 'any' with an object.

TypeError: Cannot set property 'test' of null

Code or steps to reproduce

1. Get a raw app.js, only changing the token value - or skip to Step 4 if you have an unmodified bot running the latest klasa/d.js master that you can test on.

2. Install Klasa, Discord Master:

   • npm i -S discordjs/discord.js
   • npm install dirigeants/klasa
   • npm install

3. Run the bot.

4. Add a key to your schema of type any:

+eval this.client.gateways.users.schema.add("test", { type: "any" })

5. Update someones configs, in the test key, with an Object value.

+eval msg.author.configs.update("test", { test: 'test' });

6. Reset the Object value in the test key of the users config.

+eval msg.author.configs.reset("test");

7. Update the users config again, in the test key, with an Object value.

+eval msg.author.configs.update("test", { test: 'test' });

8. Observe error: TypeError: Cannot set property 'test' of null. If the error doesn't appear, try rebooting the bot and trying it again.

Expected an actual behaviour

The test key in the users' configs should be updated with the Object value.

Further details

• discord.js version: v12.0.0-dev
• node.js version: v9.3.0
• Klasa version: v0.5.0-dev
• I have modified core files.
• I have tested the issue on latest master. Commit hash:

Describe the issue

We can agree that usage strings are very cool, very easy to use, very clean and readable, compared to other systems implemented in other frameworks with are, for example, an array of objects that lately face the issue of union type, something easy to write thanks to the usage string. However, as easy as it is, the usage string has one weakness that we can't address in the current way, for that, I have multiple proposals.

UsagePrompt

This is @MrJacz's proposal, an array typeof Array<string | (msg: KlasaMessage) => string. This is the easiest way to address this issue as it's another property for CommandOptions: usagePrompt. It's usage would come to be something similar to:

{
    usage: '<battletag:string> [bronze|silver|gold|platinum]',
    usageDelim: ' ',
    usagePrompt: [
        'Give me a battletag formatted as username#0000',
        'Give me a rank name, can be bronze, silver, gold or platinum, pick the one that is next to your rank.'
    ]
}

However, it's lineal and to do so you may need to pass empty values or undefined in the middle of the array, to address that, it's possible to have a class do that:

{
    usage: '<battletag:string> [bronze|silver|gold|platinum]',
    usageDelim: ' ',
    usagePrompt: new UsagePrompt()
        .addPrompt(1,
            'Give me a rank name, can be bronze, silver, gold or platinum, pick the one that is next to your rank.')
}

Where 0, being <battletag:string>, would use the default message (battletag is a required argument).

However, it may be confusing, may it start with zero? Or maybe with one? To address this issue, we could make CommandOptions.usage accept more types: not just string.

ArgumentUsage

{
    usage: new ArgumentUsage()
        .addParameter('battletag', /(\w{4,12})#(\d{4,5})/, true,
            'Give me a valid BattleTag, should be formatted like someuser#0000')
        .addParameter('rank', 'bronze|silver|gold|platinum', false,
            'Give me a rank name, can be bronze, silver, gold or platinum, pick the one that is next to your rank.'),
    usageDelim: ' '
}

Where ArgumentUsage is a class that compiles directly to ParsedUsage and has a .toString() method to compile to usageString (used in the help command, for example). The reason this would compile to ParseUsage is so it's able to add the new properties to the possibles: promptMessage being either a string or callback (msg: KlasaMessage) => string.

The Argument#addParameter option is very powerful as it doesn't only add one more feature to Usage, which is prompt, but it also adds two more (nice) features: the possibility to have raw RegExp to use as regexp type (I'll be honest, I haven't figured the RegExp type since it got released, it's very complicated inside usageString, if this gets merged, the usage of the RegExp type in Klasa will be significantly easier) or even a custom type. Of course, this part of the concept can change, and name would be... perhaps custom or allow a fifth parameter which is parameter name for usageString. This can be reviewed later.

Furthermore, stringifying a RegExp for usageString is relatively easy, RegExp#toString() does that.

This method would also support strings as legacy and would allow union type. Of course, this could use the current usageString parser, covering the downsides of the systems that are not based in quotedString.

The design of this method is inspired on PermissionLevels to keep the design of the framework and its core pieces.

EDIT: Stringifying an ArgumentUsage instance would be as easy as mapping all the entries and write argName:typeName/typeParam then wrap with < and > or [ and ] depending on whether the value of the second parameter is true or false.

class ArgumentUsage {

    public constructor();
    private _entries: object[];

    public addParameter(
        argName: string, 
        type: string | RegExp | (msg: KlasaMessage, arg: string) => string,
        required: boolean,
        promptMessage?: string | (msg: KlasaMessage) => string,
        typeName?: string): this;

    public toJSON(): object;
    public toString(): string;

}

EDIT 2: ArgumentUsage is not meant to replace the former usageString, but to complement as a more advanced tool that opens the gates for more creativity, implementing better debugging (IntelliSense, separation of the "parts" of each Tag, custom types, better RegExp readability...) and the possibilities to reach where usageString can't reach while also using the parser for the aforementioned to cover the issues this kind of system has in other frameworks (lack of union type as an example).

This is more than just an enhanced usage, this allows better debugging, better internationalization, custom messages/prompts (feature highly requested over almost half a year) and improves user friendly-ness towards users.

Implementation

None.

Further details

• PermissionLevels

Describe the proposal

Since SGv1, in the PR #255 from Komada, we had the first implementation of SchemaPiece being able to store more than a single value of the same type (instead of being type array, from the former configuration system).

However, this system is extremely old and should be renamed and refactored into something much better, in this proposal, I'll use SchemaPiece#multiValue as a placeholder for a better name.

What does SchemaPiece#multiValue do compared to SchemaPiece#array? The current name limits the options, the values may be contained inside an array or not, but, what if I want to use Set or Map? The current system does not allow it, but multiValue will.

Implementation

There are multiple ways to achieve this, but I'll present two in this proposal:

ValueController

This is more versatile, it allows custom types and moves some of the heavy work from SG to them, it also allows users to implement their own ValueController, for example, one being Collection extending Map and so on. Compatibility with string for simplicity in SchemaFolderAddOptions is accepted with a later resolve.

Said ValueController would implement basic methods such as create, clone, add, remove and modify and they could be stored in GatewayDriver together with the available key types.

Internal Resolving

This is less customizable and more hardcoded, plus makes SettingGateway's internals much heavier. These methods would be integrated in a different file (similar to a util) for later usage.

In both options, you'll be able to do

SchemaFolder#add('tags', { type: 'string', multiValue: 'Map' });

And the new values will be stored in the Map. However, some of the multiValue may not be able to be directly configurable, so they'll have the same behavior as type: 'any': sets SchemaPiece#configurable to false.

This proposal is not merging on #179 but in a later one.

Describe the proposal

Currently Provider#getAll wants just the table, and expects to return all the data. That is horrible, because that means you could potentially be fetching thousands of documents for no apparent reason. (not to mention in

This proposal suggests adding an optional array of ids to the getAll functions, where each provider has to handle it manually (most databases have ways of doing this. Mongo has $in, most of sql seems to have select item from table where item.id in (values, here), rethink can do filtering, etc.)

Example Code

async getAll(table, filter = undefined) {
    if (util.isArray(filter)) {
        // Fetch data based on the filter, where each item in filter is the id
        // for instance, assuming we have sql
        return this.run(`SELECT * FROM ${table} AS g WHERE g.id IN (${filter.join(",")})`)
    }
    // Fetch all data like normal
}

Expected and actual behaviour

This should return all data if no array is provided, or filtered data otherwise. This should NOT have to fetch all data and return the correct one, but should rather integrate with the database's syntax and fetch exactly whats needed at once.

Further details

• discord.js version: not relevant
• node.js version: not relevant
• Klasa version: 0.5.0-dev
• I have modified core files.
• I have tested the issue on latest master. Commit hash:

When you issue the command to disable the message event. It should not let you, but yet it does.
It's simple to fix the problem. All that needs to be done is change Message to message. (See the code below)

// peice.name === 'Message' should actually be piece.name === 'message'
async run(msg, [piece]) {
		if ((piece.type === 'event' && piece.name === 'Message') || (piece.type === 'monitor' && piece.name === 'commandHandler')) {
			return msg.sendMessage(msg.language.get('COMMAND_DISABLE_WARN'));
		}
		piece.disable();
		return msg.sendCode('diff', msg.language.get('COMMAND_DISABLE', piece.type, piece.name));
	}

Expected and actual behaviour

It is expected to prevent you from disabling the message event handler.
It's actual behavior, disables the message event handler and prevents you from issuing further commands.

Describe the issue

as the title already says the cmdDeletion doesn't work anymore after the cmdEditing rewrite.

Code or steps to reproduce

const { Client } = require('klasa');

new Client({
    prefix: '+',
    cmdDeleting: true,
    readyMessage: (client) => `Successfully initialized. Ready to serve ${client.guilds.size} guilds.`
}).login('your-bot-token');

Expected an actual behaviour

Delete the message if invoke message is deleted

Further details

• discord.js version: newest master (discordjs/discord.js@a5e8f05)
• node.js version: 9.10.1
• Klasa version: newest master (7de01e1)
• I have modified core files.
• I have tested the issue on latest master. Commit hash: 7de01e1

Describe the proposal

I think this term is very misleading for a property that is only there to prevent an inhibitor to be run for the help command. If we want it configurable for inhibitors to only be run in certain scenarios, this should be more configurable.

A client option which would let the user define more than the typical 10 permission levels cap.

I've noticed this bug where if u let a command prompt for 30 seconds it would return [object Map] https://i.imgur.com/N4urwsW.gif that gif shows you what I mean, I'm guessing the issue is you're awaiting messages with no error handling

Describe the issue

Code or steps to reproduce

Usage with prefix !

!blacklist @stitch#9441

Expected an actual behaviour

Blacklists me. Instead, it says "guildID must be between 17 and 19 characters.

Further details

• discord.js version: latest master
• node.js version: 10.0.0
• Klasa version: latest master
• I have modified core files.
• I have tested the issue on latest master. Commit hash:

For a long time, we have depended of the moment package, however, its i18n support is not used, as well as it is a bit hard to use, check the reference here. We could do two things:

• 1.- Remove moment as a dependency and make our own one, this would be very similar to what we did with chalk before (thanks to Faith), and we could get rid of many weird issues when using moment-duration-format. Then, our implementation could be more efficient with the latest V8 changes and easier to use.

• 2.- Modify our usage of moment so it's multilanguage. (It is used in the stats command to show how long has a bot been running for).
  

  klasa/src/commands/System/stats.js

  Line 16 in 12616ee

  `• Uptime :: ${moment(Date.now() - (process.uptime() * 1000)).toNow(true)}`,

The Message#reply method would be more useful if it supported command editing, like KlasaMessage#send, et. al., do. I am proposing that Klasa replaces that method with its own.

Version 2.5.3 of typescript just got published.

This version is covered by your current version range and after updating it in your project the build failed.

As typescript is “only” a devDependency of this project it might not break production or downstream projects, but “only” your build or test tools – preventing new deploys or publishes.

I recommend you give this issue a high priority. I’m sure you can resolve this 💪

Your Greenkeeper Bot 🌴

Apparently, on the docs, it shows this for checking the Permission level of a msg.

msg.hasAtleastPermissionLevel(#)

However, when testing this it ends up returning:
0|app | [2017-10-24 19:12:40] TypeError: msg.hasAtleastPermissionLevel is not a function 0|app | [2017-10-24 19:12:40] at module.exports.run (/home/jordan/Sistine/commands/Currency/balance.js:38:31) 0|app | [2017-10-24 19:12:40] at msg.validateArgs.then (/home/jordan/Sistine/monitors/commandHandler.js:66:19) 0|app | [2017-10-24 19:12:40] at <anonymous>

The function ends up working if you capitalize the l in Atleast to AtLeast.
https://dancing.while-at.work/3f4e0f.png

The library should not care anything about what the provider is using in the background. This also allows for each sql provider to be more customized to that individual database, rather than trying to find a set of sql syntax/types common to all sql databases. As well as reduction of core code (bloat) and finally massive simplification of SettingGateway.

Potentially add a SQL QueryBuilder Util with overridable defaults, to aid in reduction of duplicate code/making SQL Providers more maintainable.

A way to be able to have custom Prefix with regex's aka this.client.config.prefix could be new RegExp(/!/g) for example

Describe the issue

I got multiple recurring tasks that should ran every minute but what happens is that the first task runs then the second ones run in the second minute and in the third minute the third tasks runs, and a loop starts.

Code or steps to reproduce

Make multiple recurring tasks (mine hapened with the same task) with the cron "* * * * *" (that means that they should run every minute of every hour of every day, etc), after that check how the multiple recurring tasks are executing, for example if you want to do a simple test you could make a task that does console.log("test"), and that should appear n times (n being the amount of recurring tasks you made) in the console but it doesnt.

Expected an actual behaviour

What should happen is that your console should be filled of "test" but it is not because only one scheduledTask was ran.

Further details

• discord.js version: 12.0.0dev
• node.js version: 8.11.1
• Klasa version: 0.5.0dev
• I have modified core files.
• I have tested the issue on latest master. Commit hash: c6be589

Describe the proposal

The PR #228 went into stale due to the lack of an objective design and lack of a technical specification for QueryBuilder. This issue will remain opened until the design for QueryBuilder gets fully written, specified and merged into the master branch.

I'm opening this issue as QueryBuilder is part of the v1.0.0 RoadMap and therefore, its design should start taking priority so it can be written, tested and merged before discord.js 12 does, that way we can land the long-awaited Klasa 1.0.0 with discord.js 12 release.

The current (and last written) version of QueryBuilder looked like this:

// Create a QueryBuilder for PostgreSQL
this.qb = new QueryBuilder(this.client, {
	// Declare the boolean type, with the datatype name as "BOOL"
	// and defaults false and true
	BOOLEAN: { name: 'BOOL', default: [false, true] },
	// Declare the float type, defaults to 0
	FLOAT: { name: 'DOUBLE PRECISION', default: 0 },
	// Declare the integer type, defaults to 0
	INTEGER: { name: 'INTEGER', default: 0 },
	// Declare the text type, defaults to NULL
	TEXT: { name: 'TEXT' },
	// Declare the varchar type, defaults to NULL, the property of
	// size tells QB to use VARCHAR(MAX_LENGTH)
	VARCHAR: { name: 'VARCHAR', size: true }
}, {
	// When using arrays, PG converts INTEGER to INTEGER[]. So we want
	// to append '[]' at the end of the type
	arrayWrap: (type) => `${type}[]`
});

However, this design has not been approved by the team. I would also like to open this to everyone who wants to contribute in the design of QueryBuilder (perhaps we can take a look to Sequelize and Knex, and get the best of them for some aspects?).

There are some really good stuff on Klasa that use reactions and paginations and make life a lot more easier and amazing with stuff like RichDisplay and RichMenu.

I was wondering if there was a chance of incorporating something similar for awaitMessages. I use this as an application of sort and was hoping for an awesome way to do this.

it would require parameters like:
an object that shows how many different questions you need to be answered, time for each question, type of response like options which could use reactions etc

Let me know if I am not clear on the suggestion and would like more details I will be happy to elaborate.

Describe the issue

If your category has over a certain amount of commands (54 in my case) the default help commands breaks due to not correctly splitting the codeblocks (the .send() catch fires with a wrong message)

Code or steps to reproduce

1. create a category with a lot of commands
2. try to use the help command

Expected an actual behaviour

show help command correctly

Further details

• discord.js version: discordjs/discord.js@f247484 [Newest Master]
• node.js version: 9.11.1
• Klasa version: db946cc
• I have modified core files.
• I have tested the issue on latest master. Commit hash: db946cc

Version 4.10.0 of eslint was just published.

This version is covered by your current version range and after updating it in your project the build failed.

eslint is a devDependency of this project. It might not break your production code or affect downstream projects, but probably breaks your build or test tools, which may prevent deploying or publishing.

Your Greenkeeper Bot 🌴

Describe your proposal

I want an easy way to disable individual core commands.

Usecases for your proposal

I don't want to have the user-conf command in my bot. At least not in the near future. There is no nice way to get rid of it, without getting rid of all the other core commands.

Expected and actual behaviour

Currently I'd need to transfer the command file, then set enabled: false, then maybe move it into a folder called 'Disabled' or something. That is quite annoying, especially if I wanna make the bot open source. I don't want a random folder with some commands that shouldn't be touched.

I want a way to be able to persistently disable individual core commands globally, that'd work with OSS. You could put it into the Client initialization, maybe?

I really hope this is added, as this issue is really annoying me.
Thanks for reading.

Describe the issue

Almost all of the pieces' typings mark certain methods as 'abstract'.
The methods are normally optional, but the 'abstract' marking forces you to implement them.

Code or steps to reproduce

import { Command } from 'klasa';
import { Client } from '../../structures/Client';

// [ts] Non-abstract class 'default' does not implement inherited abstract member 'disable' from class 'Command'.
export default class extends Command {

	constructor(client: Client, dir: string, file: string[]) {
		super(client, dir, file, {
			aliases: ['details', 'what'],
			description: 'Provides some information about this bot.'
		});
	}

	async run(msg) {
		return msg.sendMessage(msg.language.get('COMMAND_INFO'));
	}

};

Expected an actual behavior

No errors; typescripts allows the class.

Further details

• discord.js version: 11.3.2
• node.js version: 10.1.0
• Klasa version: 0.4.0
• I have modified core files.
• I have tested the issue on latest master. Commit hash: