Auto generated migration doesnt valid for PSR12

[kirya-dev]

Bug Report

Auto generated migration doesnt valid for PSR12

FILE: /*****/migrations/Version20210129094711.php
------------------------------------------------------------------------------------------
FOUND 3 ERRORS AFFECTING 3 LINES
------------------------------------------------------------------------------------------
 15 | ERROR | [x] There must not be a space before the colon in a return type declaration
 20 | ERROR | [x] There must not be a space before the colon in a return type declaration
 28 | ERROR | [x] There must not be a space before the colon in a return type declaration
------------------------------------------------------------------------------------------
PHPCBF CAN FIX THE 3 MARKED SNIFF VIOLATIONS AUTOMATICALLY
------------------------------------------------------------------------------------------

Time: 8.3 secs; Memory: 36MB

[goetas]

You can provide a custom template, that follows any coding standard you want. See

migrations/lib/Doctrine/Migrations/Configuration/Configuration.php

Line 36 in 780b67e

private $customTemplate;

[kirya-dev]

You can provide a custom template

No. Target of this PR will change default behavior.

[guilliamxavier]

Related: doctrine/coding-standard#163 and ef842cf

[jtrupina]

@kirya-dev I also came across this. Any new updates on this issue? Also there is already open PR: #875 related to this issue. Also, @guilliamxavier I don't see that doctrine/coding-standard#163 fixed this particular issue or am I missing something.

[guilliamxavier]

@jtrupina: I didn't say "fixed"; to be clear: doctrine/coding-standard#163 updated the Doctrine CS rule for return type declarations from "1 space before colon" (historical Doctrine style) to "no space before colon" (PSR-12), and later #1102 (more precisely 53a5da0 and ef842cf) upgraded and applied the new CS to this lib (code), but left out the template (string). Thanks for mentioning #875, you're right 🙂 the thing is it was created before doctrine/coding-standard#163 so was put on hold, and seems to have been forgotten afterwards... I'll ping it 😉

[greg0ire]

I think we can close this, it will be fixed in the next 3.1.x release :)