-
Notifications
You must be signed in to change notification settings - Fork 20
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Support needed for multiple config file formats! #33
Comments
The alternative seems to be |
Maybe we should make the package.json the standard instead of config.yml? (Just an idea of course, would appreciate other opinions) |
config.yml has not been the standard since Grakkit v5. |
I don't agree with this.
What happens when the user wants to use Deno, which is a NodeJS alternative? What about when Or what happens when the user doesn't want to use How about when we need to extend additional customizations onto our config? Or the user has a need to have A good portion of our users right don't use a single method. Everyone does something different. I propose that instead of making Grakkit-specific configuration can be driven by |
Hmm, good point about deno... and now that you mention it, it does break the principle. I suppose I never gave it much thought since I didn't see a better alternative to choosing something like |
|
@Mythical-Forest-Collective I would normally agree but since Grakkit's common lib is, well, common, it makes sense to have a unified config format across all platforms. If not for that, it'd make it more complicated for people, like if two devs want to share their setup of files with another and they use different platforms, they'd have to change files around. |
Hm that's fair, though we will need a way to allow people to define where the file gets saved since every platform is different |
I think we can check for a set of supported files?
|
@MercerK I can see that being nice for the backwards-compatibility, though it would add a lot of extra code to the common library for checking an ever-growing list of supported configs. And how would we decide which ones take priority? |
As an example, NodeJS Plugins do support configs coming from different files; it just depends on what we support. For example, eslint has We can just set a read order and whichever file we find first is the one we use. However, it doesn't matter what file they use, the configuration schema should be the same. |
Hmm... wouldn't Grakkit work differently to ESLint due to platform-specific options in the config? |
Why would grakkit's configuration behave differently from the eslint configuration? It should behave the same across all files in all the same ways. It should not matter what platform the user is leveraging, that is more of a schema problem than a file problem. |
In the future, there might be config options for platform-specific things built into Grakkit's java code. Take bukkit command registry as an example. I could see Grakkit using |
No matter the platform, you can solve that with a single configuration schema with documentation (which is key). You don't necessarily need to abstract into multiple files for specific platforms. We don't have platform-specific configurations now, so I don't think scoping a future "problem" as a blocker to this is ideal. |
Hm, that's true. Though, if we do end up adding platform-specific configs, I think we can set the schema up in a way where it makes room for that. As an example... {
"grakkit": {
"main": "index.js"
},
"bukkit": {
"commandRegistry": true
},
"minestom": {
"commandRegistry": true
}
} For now, we'd just have "grakkit" and the "main" field, but we can extend this config if needed. |
I think this broke a few versions ago. Right now, it defaults to
grakkit/index.js
every time. You use to be able to use a config to change the path.The text was updated successfully, but these errors were encountered: