Doctrine Migrations set up violates PSR-4

[dbu]

In a new flex project, i added migrations and generated a migration. The dir_name is set to src/Migrations, but the migrations are created with namespace DoctrineMigrations. The code style fixer wants to change that to App\Migrations. The migrate command finds the migration file, but then tries to instantiate the class with the DoctrineMigrations namespace. The migration is also not runtime code but more of a configuration thing. I changed the configuration to place the migration in config/Migrations (without setting up autoloading) to make things work.

I am not sure what the best solution is, but placing migrations in src/ but with a totally wrong namespace (no App prefix, folder Migrations vs namespace DoctrineMigrations) is counter-intuitive and leading to confusion.

[Pierstoval]

I also think putting migrations in src is not the best option, but there was a lot of issues about migrations, like #112, #153, #172, #253…

I hope some change is coming, because it was opinionated to src 🤔

[fbourigault]

To handle such case, I use the following autoload section:

"autoload": {
    "psr-4": {
        "App\\": "src/"
    },
    "exclude-from-classmap": [
        "/src/Migrations/"
    ]
}

[stof]

That's done on purpose, because doctrine/migrations does not rely on autoloading at all either (and I think that having any migration class autoloaded before the library runs the command might even break its location of available migrations)

[ghost]

The bundle documentation mentions nothing about changing the namespace. Without @fbourigault's changes this recipe won't work well out of the box.

[dkarlovi]

I do the same thing as @fbourigault, with this:

doctrine_migrations:
    dir_name: "%kernel.project_dir%/src/App/Infrastructure/Doctrine/Migration/ORM"
    namespace: App\Infrastructure\Doctrine\Migration\ORM

[stof]

@jrobeson the recipe works fine out of the box, because doctrine/migrations does not expect migration classes to be autoloadable (quite the opposite)

[dbu]

yep, it works. but it violates PSR by placing files in src/ with a wrong namespace.

[ChangePlaces]

As a codebase that seems to follow so many formal guidelines and best practices, it seems bizarre that it's turning its eye to this issue.

[fabpot]

Closing as this is related to Doctrine migration, not Symfony. Nothing we can do here.

[mrsax]

To handle such case, I use the following autoload section:

"autoload": {
    "psr-4": {
        "App\\": "src/"
    },
    "exclude-from-classmap": [
        "/src/Migrations/"
    ]
}

The problem is that one will not be able to make migrations anymore...

Better is to exclude it in the service.yaml so one doesn't get problems with tests etc either
services.yaml

App\:
    resource: '../src/*'
    exclude: '../src/{DependencyInjection,Entity,Migrations,Tests,Kernel.php}'

add the "exclude" line and you're set and migrations still work and composer.json still calls for PSR-4 as it should.

[adrianrudnik]

Just to make sure, this recipe and the use of migrations with their weird namespaces prevents any use of composer dump-autoload --classmap-authoritative and the optimizations that come with that correct?

[stof]

@adrianrudnik no it does not. the whole point of this is that migrations classes must not be autoloaded. the doctrine/migrations library loads these classes in a special way, and letting the autoloader load them would mess with that logic.