bug: getNearestCommand main use case being unreachable for custom prefixes

[carafelix]

Currently the main use case for getNearestCommand is to work as a 404 for messages containing unknown. commands Example:

// after all our command registration
bot
   .filter(Context.has.filterQuery('::bot_command'))
   .use(async (ctx) => {
      const suggestedCommand = ctx.getNearestCommand(myCommands)
   })

A command registered with a custom prefix, would never trigger the filter ::bot_command, like +doX

As me and @roziscoding talked, it's needed to overwrite the ctx.entities("bot_command") method for one that hydrates with not only commands entities, but also commands registered with custom prefixes

A ready to use 404 function could also be useful, e.g:

// after all our command registration
bot.use(
   command404(
      'did you mean $COMMAND',
      'msg for not found',
   ).localize('es', 'quisiste decir $COMMAND', 'comando no encontrado'),
)

[roziscoding]

I think we don't really need the commandNotFound middleware. As you said somewhere else (I don't remember where lol) this can be easily achieved with i18n + getNearestCommand and a simple example on the docs would be enough

[carafelix]

a simple example on the docs would be enough

Yeah, I forgot lol.

In any case, we have to come with a 404 implementation that does not depend on Contex.has.filterQuery(::bot_command), maybe implement some static method inside the Commands class, that archives the same thing + commands with custom prefixes. I'll come up with something soon

[roziscoding]

@carafelix we could add a different function, perhaps something like commandEntities, that would call ctx.entities("bot_command") and return that + custom prefixed commands. It'd probably need to take in the commands tho, or it'd be an instance method to the Commands class.