Suggestion: Add other interaction types as seperate folders

[cesarheuvelmans]

Would love to see seperate handler paths for buttons, selectmenus, modalsubmits, contextmenus and autocompletes. With the filenames corresponding to the custom ids off those components. e.g.

[NotM1Dev]

Could you clarify more? Do you mean something like this?:

src/
    buttons/
    autocomplete/
    modals/
    menus/
        select/
        context/

[cesarheuvelmans]

Yes, exactly. And then in those folders you would be able to place the handlers for those types of interactions. Basically the exact same way the commands and events folders work in commandKit now. Maybe autocomplete doesn't need a seperate folder since it's already handled within command files themselves. But being able to split up buttons, menus and modals into seperate folders would be a game changer. Otherwise they would all fall under events/interactionCreate/.
So preferably you would be able to do something like this:

src/
    buttons/
        customIdExample1.js
        customIdExample2.js
    autocomplete/
    modals/
    menus/
        select/
            customIdExample1.js
        context/

Where src/buttons/customIdExample1.js would only execute when an interactionCreate event is received with type = 3(message component) & component_type = 2(button) & custom_id = 'customIdExample1'

[NotM1Dev]

Personally I think this would turn CommandKit into some Next.js framework for discord.js, which doesn't make it beginner-friendly as it's currently advertised.

[twlite]

On Project Structure

We plan to introduce a well-organized project setup that is easy to use over a long period. This is currently under internal discussion to find the best solution.

I feel this might make CommandKit similar to the Next.js framework for discord.js, which may not be as beginner-friendly as it is now.

This idea isn't complex, considering CommandKit's design to automatically handle commands. However, having many customIdExampleX.js files can be confusing. We won't enforce this method, but we'll definitely provide an alternative.