Configuration via initializer and components path
cseelus opened this issue · comments
Found this gem through the Evil Martians blog, nice idea to make a gem out of it.
How does the configuration via initializer work exactly, like so?
Komponent.configure = {
stimulus: true,
locale: true
}
Also is it possible to change the default component path from frontend
to say app/frontend
?
Hello @cseelus,
You can configure Komponent generators by defining global options for both generators in an initializer:
config.generators do |g|
g.komponent stimulus: true, locale: true # both are false by default
end
So next time, you generate a component, flags you're defined should be used.
Yes, it's possible to change the default component directory by overriding component paths in an initializer:
Rails.application.config.komponent.component_paths = [Rails.root.join("app/frontend")]
Hello @florentferry and thanks for the fast reply.
I should have been clearer, I read the docs, what I meant is, if its possible to change the default path for components or if this feature may be planned?
So that this path is also used when generating components. The following setting does affect component generation for me:
Rails.application.config.komponent.component_paths = [Rails.root.join('app/frontend')]
Also I'm not getting the options for stimulus and locale to work via an initializer file, like so:
Rails.application.config.komponent.locale = true
Yeah, the setting does not affect generation. Like component_paths
is used to resolved several endpoints, I don't think the setting should modify the location where components are generated. But an option on generator can be the right way to do that. Actually they are no options for that, but we can add it.
This options need to be defined on generators:
Rails.application.config.generators.komponent.locale = true
Thanks again, thought I had tried Rails.application.config.generators.komponent.locale
, but well … 😅
An option for the generator would be most welcome, as moving the generated files manually and deleting /frontend
after each invocation defeats the purpose for anyone using a different folder somewhat.
So I implemented the feature you have requested, I let you check #43 to ensure it responds to your use case.