Closed maidmaid closed 6 years ago
we could even handle a tag so that makers could be provided by bundles
Not sure it's needed because a maker is just a console command whose name starts with make:
Short answer: yes, we want these commands :). I’m planning several varieties of guard auth make commands.
About extensibility, we do want to empower other bundles to add make commands. Probably they can/should just extend our base class. Or, a separate class with an interface might be even better.
Javier - it’s true that anyone can just create a make: command. But we need just enough extensibility so that those commands can have the same look & feel :)
Great :) Note that extending the base command might be a stronger coupling than providing a service ppl could use instead. Either way, we need to be careful to make the maker-bundle a mandatory requirement of all other bundles that want to hook into it.
May be make:kernel
to create separated kernels eg a front script that loads ApiKernel with another set of bundles … configs
Though the prefix for kernels in the new sf has been remove so not sure how will be the new or best practice approach to achieve this.
@luishdez thanks for your proposal. The problem is that newer Symfony versions (specifically Symfony 4 with Flex) is discouraging the creation of multiple-kernel apps. Instead it's recommending the creation of multiple small apps.
Making bundle have/has a tag is better than create an command with make as prefix
The problem is that newer Symfony versions (specifically Symfony 4 with Flex) is discouraging the creation of multiple-kernel apps. Instead it's recommending the creation of multiple small apps.
@javiereguiluz not sure about that, it depends, we might need two kernels (or just one vKernel) to create API projects (the API front and its Admin and docs zones) and they probably share a lot of things that in two separate apps would be duplicates (e.g. entities, some services, config, etc) Btw, unrelated my comment, sorry for that.
@ad3n I don't see how. We would still have to register a command for each of them, and all the configuration of the command would have to depend on this services (as we cannot assume which argument the generator needs). Creating an interface replicating the command configuration API entirely is not worth it. A command is also just a service anyway.
@maidmaid I'm closing this issue because it's one of those meta-issues which ask lots of things and end up generating an eternal discussion. Let's open 1 issue per proposed command (we already have issues for some of these proposals) and please, add some usage examples, the exact list of options/arguments per command, etc. Thank you!
The documentation covers a lof of other boilerplates, but theses one are less common. So, we can imagine the next commands:
make:security:guard
docmake:serializer:encoder
docmake:profiler:data-collector
docmake:security:form-login
docmake:monolog:processor
docThis bundle is interested only by the most common makers or these previous examples are potentially to include in this project?