Support for configurable Flex directories #2
Comments
|
we have a related issue for Flex too: symfony/flex#196 |
|
Another option would be to not support this feature. Someone who changes the |
|
Isn't it just getting or injecting |
|
I go one level deeper than src for my Symfony related code in my apps. I would benefit from some kind of namespace option (a config option could do the trick) |
|
Is the hardcoded App Namespace not a similar issue? I was a bit shocked that we would be forced to an "App" prefix for our entire application src if we want to be able to use the makers. And moving the business logic out of src is not really an option, tbh. |
|
Well, Flex itself does not support changing the namespace (as it would force to make all recipes much more complex than just copying some files).. This is why the scope of the initial request here is to support what is supported on the Flex side. |
This PR was merged into the 1.0-dev branch. Discussion ---------- Allow generation into sub-namespaces Three changes: 1) Generation is now allowed into sub-namespaces: e.g. `make:controller` passing it `Admin\MainController` would generate into `src/Controller/Admin/MainController.php`. 2) You can pass absolute class names now too - e.g. `OtherNamespace\Controller\FooController`. Maker reads the Composer autoloader to figure out where this should live - e.g. `lib/Controller/FooController.php`. This fixes #2: Maker follows your autoloading rules to find *where* to generate things. 3) [BC] Break for anyone with custom makes: the `MakerInterface` was updated to be much simpler. Instead of `getParameters()`, `getFiles()` and `writeSuccessMessage()`, you just implement `generate()` and do it all in one method. I think using this library to create custom maker commands is still quite uncommon (we are listed as dependencies of VERY few projects on Packagist), so I think we should make this change versus keeping BC code paths for a long time in the future. Cheers! Commits ------- 5d1b976 Fixing possible non-existent dir in test 38f7887 fixing tests 6b2f56f phpcs dccaea1 Fixing bad method & only generating entity if it exists 9e90cbc Adding support for passing \Absolute\Class\Paths as class names c9617ba Minor tweaks - removing extra "." in text and making twig extension interactive 7f02ed1 Maker error message show the relative paths f8d3e09 Making the maker write changes so they can control message ordering 2da8b65 removing php 7.1 code 27ac258 doc'ing BC break aabbedf Refactoring MakerInterface to be more straightforward 5261d6d Updating templates
symfony@ffc80c4 added 'string' as type hint for Symfony\Bundle\MakerBundle\Util\ClassSourceManipulator::addSetter()'s $type. However, ClassSourceManipulator::addEntityField() will call addSetter() with $type == null for all custom defined fields and even for builtin type 'blob'. That results in a type error when (re)generating entities: TypeError: Symfony\Bundle\MakerBundle\Util\ClassSourceManipulator::addSetter(): Argument symfony#2 ($type) must be of type string, null given
Currently, the generators are hardcoding the
srcfolder for the source. ButSRC_DIRis configurable in Flex.The bundle should read the configured value in the composer.json instead, to account for Flex configuration.
The text was updated successfully, but these errors were encountered: