Below is my suggestion:

Having the easy ability to set an option in each command where people can decide whether the command can be performed in DMs only, Guilds only OR Guilds & DMs.

AJFire14#1004

dab I mean is this allowed?

🚨 You need to enable Continuous Integration on all branches of this repository. 🚨

To enable Greenkeeper, you need to make sure that a commit status is reported on all branches. This is required by Greenkeeper because it uses your CI build statuses to figure out when to notify you about breaking changes.

Since we didn’t receive a CI status on the greenkeeper/initial branch, it’s possible that you don’t have CI set up yet. We recommend using Travis CI, but Greenkeeper will work with every other CI service as well.

If you have already set up a CI for this repository, you might need to check how it’s configured. Make sure it is set to run on all new branches. If you don’t want it to run on absolutely every branch, you can whitelist branches starting with greenkeeper/.

Once you have installed and configured CI on this repository correctly, you’ll need to re-trigger Greenkeeper’s initial pull request. To do this, please delete the greenkeeper/initial branch in this repository, and then remove and re-add this repository to the Greenkeeper App’s white list on Github. You'll find this list on your repo or organization’s settings page, under Installed GitHub Apps.

An info command which holds key summary (aim & features) in basic form of spark, version, invite to support server & link to website. This command will be a default one for all bots using Spark framework.

There should be commands to reboot and / or reload parts of the bot
!reboot => Stops the bot, so when used with pm2 and such, it will relaunch it.
!reload => Reloads the bots files, so you can for example work on a command, without having to reboot your bot.
reload should have subcommands like:
!reload commands => Reloads commands
!reload MF / messagefunctions / message => Reload message functions
!reload BF / bootfunctions / boot => Reload boot functions
!reload cmds / commands => Reload commands
!reload snippets => Reload snippets
!reload functions => Reload boot, message and snippet functions.
!reload permissions / perms => Reload permissions

Although both names are very good at explaining what they do, it's better to have a shorter word that is like one word. Both in communication and in (source) code.

Each command currently has a description, I'd love to add args schema and an extra help text which will be displayed when help is called

The point is not to build a separate help.js

Currently if specified in the config that Spark should ignore bots, it will also ignore it in message functions, which could be problemetic for message scanning, autodelete in a channel, etc.

I want to change
allowBots: true
to
allowBots: true For ignoring message function and commands
allowBots: "message" For only ignoring commands.
allowBots: "command" For only ignoring messagefunctions

🚨 You need to enable Continuous Integration on all branches of this repository. 🚨

To enable Greenkeeper, you need to make sure that a commit status is reported on all branches. This is required by Greenkeeper because it uses your CI build statuses to figure out when to notify you about breaking changes.

Since we didn’t receive a CI status on the greenkeeper/initial branch, it’s possible that you don’t have CI set up yet. We recommend using Travis CI, but Greenkeeper will work with every other CI service as well.

If you have already set up a CI for this repository, you might need to check how it’s configured. Make sure it is set to run on all new branches. If you don’t want it to run on absolutely every branch, you can whitelist branches starting with greenkeeper/.

Once you have installed and configured CI on this repository correctly, you’ll need to re-trigger Greenkeeper’s initial pull request. To do this, please delete the greenkeeper/initial branch in this repository, and then remove and re-add this repository to the Greenkeeper App’s white list on Github. You'll find this list on your repo or organization’s settings page, under Installed GitHub Apps.

Includes a summary of Spark's aim & features. Include necessary links too.

Although the system we currently use works, it can be improved, lots.

Starting with the snippets system, i want to change some stuff around.
Snippets currently use this format:
client.snippets.get("snippet-name')(client, etc)
I want to change this to these 2 structures:
client.snippets.snippet-name(client, etc) and
client.snippets.list("snippet-name")
In the last case snippet-name is optional, it will return a list of names if null.

Have an import method, like client.customConfig.import(arg)

arg can be an array or map, with the config intern
for example:

var data = {guildId: "1234", data: {prefix = ["!"]}}
client.customConfig.import(data)

or

var data  = new Map()
map.set("1234", {test: true})
client.customConfig.import(data)

For now the whole permission system has been 1 glorified message filter

i want to make a system where permissions can be added in permission files, making it easier to share or update.

• functions
• commands
• permissions
  • Member.js
  • Admin.js
  • Owner.js

For multiple reasons, disabling certain things, like for example commands could be useful so people don't touch that one broken piece of code to make sure people don't abuse it.

• Add in the config section
  disabled: {commands: ["about"]}
  or:
• Add in the custom configs
  message.guild.customConfig.disable("commands", "about")

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

Version 5.0.2 of mocha was just published.

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

mocha 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 🌴

This could look something like:

disableDefault: true (startup only)

Event file loader should be added, although it may not be implemeted right away due to priorities, it should at least be implemented to make developement in the future easier.

For the reload command, Spark v0.0.x used to edit the "Reloading" message to "Successfully reloaded x commands". However. Spark v0.1 sends "Reloading all files..." then sends "Successfully reloaded all files." in a new message.

It would be better if it edited the "Reloading" message instead of sending a new one.

The framework's basic system to get the prefix(es) of the bot always responds, even if you type anything behind it, which is not useful for adding like a chat system for example

Error located at Picture
Error: Picture
It seems to me this is a flaw in Spark's coding?
"AllowedImageSizes"

Basically adding the option to "import" some config options for a single guild only (for example prefix)

client.addCustomConfig("248505281741455360", {prefix: "S!"})

• Mention to get list of prefixes or help command.
• Multiple prefix support

Reloading using --git chrashes the bot

TypeError: exec is not a function

I have some goals i want to do with the update check module.

1. I want the updatecheck to get smarter,
   "scan" through code to see if some commands should be changed or if some code is going to be removed, and instructions on how to solve them. This would make it easier for users to stay on the latest versions.

2. Better upgrade indicator, instead of saying "there is a new update (versionnumber)" show more info on what is new.

It could look something like this:

Update (versionnumber) is ready to download, core changes include:

• thing 1
• thing 2

Run spark-update test to help decide if you are ready, by running a test to determine what needs to be changed.

Run spark-update changelog to get the full changelog.

Run spark-update install to try to update for you.

When you click the "Getting Started" link it brings you to a 404 not found page.
I think the correct link is: https://discordspark.com/getting-started

Currently there is only 1 permLevel recognition from the config that is bot owner.

Preferably add a few more like botAdmin and botModerator to it and then it gets the ID's of users from the config and then applies them.
It would be a usefull as it could also be used so that it can represent which level the user is to use a specific command.

Also an id option could be added (manually setting a list of users that are allowed to have this permission level globally
or an role name option that would check if an user has a role with the name specified (checking capital letters could be disabled if prefered)

Whether your command will be ignored in a certain location.

Possible channel types that can be ignored:

• DM
• Text

The help command doesn't respond if you can use over 25 commands and it has the embed links permission.

The bot chrashes if the permission folder isn't created. This happens only on initial boot, after that it has generated the folder and all is fine.

Say how many are normal and how many are default for each

I would like to add native Event support,
you would have a folder like /functions or /commands, just with /events
Structure of an event file:

.name = String (Just for identification purposes when an error occurs. and to store it in the system)
.event = String (Is event name "ready" or "message", etc.)
.function = Function (function that happens when event is triggered)

Instead of just reloading using "commands" or "functions"

Keeping it blank should reload everything.

reload
or
reload all
to reload all.

Hello. Below is my suggestion of what could be added to Spark to improve organisation:

• Adding subfolders to commands. Basically, within the commands folder, the easy ability to create subfolders inside it to keep commands neatly in different sections for example:

Bot
Commands
> Moderation
> Utility
> Example 3 etc...

AJFire14#1004

This will display all information about the overview of commands and specific information about them.

Will Include:

• Name
• Description
• Alias'
• Permission Level
• Disabled or not

Also adding description field to every command file so that it can briefly describe the command.

In recent tests boot functions take longer to load then any other type, while having less properties and default amounts in the code.

This needs a review and possible rewrite to make loading bootfunctions faster