Update config example to match flex recipe. #523
Conversation
Update config example to match the flex recipe, since the included example ("App\Migrations") went directly against it.
|
Can you please post a link to the PR that changed the flex recipe? |
|
I'll look for it. I'm only aware because of this because today cloned a new project today, and realized the docs didn't match the recipe advice. |
|
I don't know if I'm missing something, but it seems to have been like this forever? |
| 'AnotherApp\Migrations': '/path/to/other/migrations' | ||
| 'SomeBundle\Migrations': '@SomeBundle/Migrations' | ||
| # namespace is arbitrary but should be different from App\Migrations | ||
| # as migrations classes should NOT be autoloaded |
There was a problem hiding this comment.
Can you explain what this means?
There was a problem hiding this comment.
As I understand it, that migrations should not be autoloaded by the Symfony service container build process.
There was a problem hiding this comment.
Hmmm isn't what you're thinking of called auto discovery, or do you really mean PHP autoloading ?
There was a problem hiding this comment.
No, I didn't mean autoloading in the sense of "class autoloading", as provided by the composer autoloader. I meant being loaded and configured by the dependency injection component.
In any case, not using an "App" namespace would likely prevent both things in most scenarios targeted by the docs, so not sure if the difference is of actual relevance.
But frankly, I just meant to duplicate what the recipe said, since the docs seemed to me to be deferring to the recipe; and only including a default config for cases where Flex wasn't installed, and the recipe wasn't applied.
I actually didn't really think through if the recipe was actually right and the docs wrong, or vice versa. Maybe it's better I close my PR and let someone more knowledgeable or with more time to research to help with this.
Sorry I can't be of more help.
There was a problem hiding this comment.
I was asking just in case you knew, or had the time to research, but I think I can find out.
Following the last link you provided, a few extra clicks lead to symfony/recipes#172
A bit more clicking leads to symfony/recipes#343 (comment), which corroborates that it really is PHP autoloading that is meant here. I'm not saying I understand why autoloading a migration class would break the mechanism that loads migration classes from a directory, but I think PHP autoloading is really what was meant here. Maybe @stof can help with this?
| @@ -41,12 +41,11 @@ application: | |||
|
|
|||
| # config/packages/doctrine_migrations.yaml | |||
|
|
|||
| doctrine_migrations: | |||
There was a problem hiding this comment.
🤔 why are you removing this? It still appears here: https://github.com/symfony/recipes/blob/0d06144589aeb8eff11025d398f724f9545fab2c/doctrine/doctrine-migrations-bundle/3.1/config/packages/doctrine_migrations.yaml#L1
Update config example to match the flex recipe, since the included example ("App\Migrations") went directly against it.