Upgrade Symfony 6.0 dependencies #1914

fabianoroberto · 2021-11-30T14:15:57Z

On this PR:

Fix no support for symfony 6 #1913
Restrict to only supported Symfony versions https://symfony.com/releases

fabianoroberto · 2021-11-30T14:33:00Z

Check failed because api-platform has not released a version supporting Symfony 6 yet (they are working on this).
There is an issue for that api-platform/core#4543

dougetovski · 2021-12-09T11:16:02Z

We should also keep in mind that Symfony 6 will define return types. Only updating composer.json to accepts ^6.0 without defining types on Symfony methods that NelmioApiDocBundle override may cause problems.
Correct me if i'm wrong.

fabianoroberto · 2021-12-09T11:30:31Z

@dougetovski you're absolutely right, my fault.
Maybe we could use Rector (https://github.com/rectorphp/rector) to plan the migration.
I'll try ASAP

@return

* fixed : add doc blocks to silence Symfony deprecations Symfony 5.4 returning deprecations about ``` User Deprecated: Method "Twig\Extension\ExtensionInterface::getFunctions()" might add "array" as a native return type declaration in the future. Do the same in implementation "Nelmio\ApiDocBundle\Render\Html\GetNelmioAsset" now to avoid errors or add an explicit @return annotation to suppress this message. ``` * fixed : native hint

* add zircore/swagger-php v4 to composer.json * fix incompatibilities * add compatibility with 3.2 * Apply fixes from StyleCI * mark SetsContextTrait as internal * Bump php version Co-authored-by: Alexey <alshenestky@icloud.com> Co-authored-by: Alexey Alshenetsky <alshenetsky@users.noreply.github.com> Co-authored-by: Guilhem Niot <guilhem@gniot.fr>

* Adding ``header_block`` Twig Block In attempting to remove the default green header from the API docs (I am integrating the docs into a site that already has a header), I have found that the only possible way to do so is to overwrite the entire ``index.html.twig`` file. This is because the existing ``{% header %}`` twig tags are placed *inside* the ``<header>`` HTML tags. So, if one overrides the ``{% header %}`` block, it only adjusts the header content, as opposed to allowing control over the entire header object. To resolve this problem I considered two methods: - Move the existing ``{% header %}`` tags _*outside*_ of the ``<header>`` tags. This would resolve the problem in the simplest fashion, but would be a breaking change for those currently overriding the block. - Add a new twig block, placing its tags *_outside_* the existing ``<header>`` tags. This would leave the existing functionality as-is, and would not break any current implementations. I chose the latter for the reasons specified above, and suggested the name ``{% header_block %}``. Thanks for considering this proposal. * Add Location of Original Twig Template This doc page advises that one can `have a look at the original template to see which blocks can be overridden`, but does not say where the original template can be found. This edit adds that information so that users don't have to resort to searching for keywords (like I just had to). Note that I haven't run any tests as this is a docs-only change.

…elmio#1918) * add null check nelmio#1909 * less code is better * add tests for ControllerReflection::getReflectionMethod() * lint fix * style_ci fixes Co-authored-by: Alexey <alshenestky@icloud.com>

…ort to symfony < 5.3

…dependencies' into feature/1913-upgrate-symfony-60-dependencies # Conflicts: # .github/workflows/continuous-integration.yml # composer.json

GuilhemN · 2021-12-14T13:16:34Z

composer.json

@@ -15,41 +15,41 @@
        }
    ],
    "require": {
-        "php": ">=7.1.3",
+        "php": ">=8.0",


I don't think we should bump the php version yet, PHP 7 is still widely used (see https://blog.packagist.com/php-versions-stats-2021-1-edition/).
Moreover unlike Symfony, we don't have enough resources to keep providing bug fixes to older versions for people still using php 7.x, so I'd rather stick with a constraint allowing to provide bug fixes to most of the users of this bundle with minimum maintenance load.

Make sense. Maybe could be drop support for php <7.4 (https://www.php.net/supported-versions.php) and symfony <5.3 (https://symfony.com/releases)

GuilhemN · 2021-12-14T13:21:11Z

composer.json

        "ext-json": "*",
        "doctrine/annotations": "^1.11",
        "psr/cache": "^1.0|^2.0|^3.0",
        "psr/container": "^1.0|^2.0",
        "psr/log": "^1.0|^2.0|^3.0",
-        "symfony/config": "^4.4|^5.0",


Is it making things harder to keep supporting Symfony 4.4?
If not, I'd rather keep supporting it, the argument is the same as for PHP 7.x, I think we should keep our constraints as loose as possible, both to simplify the maintenance work, and provide bug fixes to more users :)

(And actually Symfony 4.4 will receive bug fixes until the end of 2023)

As above, I can reintroduce support for ^4.4|^5.3|^6.0, but I need revert some useful changes like str_* or union types available as of PHP 8.0.0.

b1rdex · 2021-12-21T03:22:15Z

Util/ControllerReflector.php

@@ -20,46 +20,37 @@
 */
 class ControllerReflector
 {
-    private $container;
+    private mixed $controllerNameParser;


This should have a default value (null) or the line 67 will lead to a fatal error (if ($this->controllerNameParser)

b1rdex · 2021-12-21T03:36:21Z

Annotation/Model.php


    /**
     * @var string[]
     */
-    public $groups;
+    public array $groups;


This will lead to fatal errors too: only $type is required.

b1rdex · 2021-12-21T03:39:57Z

There are tons of hidden fatal errors. I'd recommend splitting the MR to a) allowing sf 6.0 and then b) upgrading to PHP 8 if necessary.

Also, introducing some static code analysis (PHPStan or Psalm) would ease PHP 8.0 upgrade, helping to find the errors.

michaljusiega · 2021-12-21T06:14:03Z

I also thinking about spliting this PR.

For me now, this bundle is blocker to bump my projects with Symfony 6.0.

GuilhemN · 2021-12-21T12:57:05Z

I merged #1933 with your changes limited to the upgrade to symfony 6.0.
We should be all good, all that remains is to make a release of it :)

For migrating to PHP 8 and Symfony > 5.3, I'm still not in favor of it, this is not necessary and wouldn't really ease the maintenance so for me it should be delayed.

GuilhemN · 2021-12-29T12:19:44Z

I'm closing this as its main goal is fulfilled, feel free to reopen this PR or a new one if you feel the need.

feat(dependencies): nelmio#1913 - upgrade symfony 60 dependencies

c6ee3ef

encreinformatique and others added 5 commits December 11, 2021 13:58

Fix deprecations (nelmio#1923)

a184cb8

try fix nelmio#1876 (nelmio#1919)

a041c69

This was referenced Dec 11, 2021

no support for symfony 6 #1913

Closed

Updated symfony dependencies. See #1925 #1926

Closed

alshenetsky and others added 5 commits December 12, 2021 01:32

Add missing null check to ControllerReflector::getReflectionMethod (n…

7de49bb

…elmio#1918) * add null check nelmio#1909 * less code is better * add tests for ControllerReflection::getReflectionMethod() * lint fix * style_ci fixes Co-authored-by: Alexey <alshenestky@icloud.com>

feat(dependencies): nelmio#1913 - upgrade symfony 60 dependencies

969e2cd

WIP: nelmio#1913 - update codebase to work with php 8.0 and drop supp…

f035797

…ort to symfony < 5.3

Merge remote-tracking branch 'origin/feature/1913-upgrate-symfony-60-…

807e89b

…dependencies' into feature/1913-upgrate-symfony-60-dependencies # Conflicts: # .github/workflows/continuous-integration.yml # composer.json

WIP: nelmio#1913 - apply patch of StyleCI

b4eda4a

GuilhemN reviewed Dec 14, 2021

View reviewed changes

b1rdex reviewed Dec 21, 2021

View reviewed changes

GuilhemN closed this Dec 29, 2021

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Upgrade Symfony 6.0 dependencies #1914

Upgrade Symfony 6.0 dependencies #1914

fabianoroberto commented Nov 30, 2021

fabianoroberto commented Nov 30, 2021

dougetovski commented Dec 9, 2021 •

edited

Loading

fabianoroberto commented Dec 9, 2021

GuilhemN Dec 14, 2021 •

edited

Loading

fabianoroberto Dec 14, 2021

GuilhemN Dec 14, 2021 •

edited

Loading

fabianoroberto Dec 14, 2021

b1rdex Dec 21, 2021

b1rdex Dec 21, 2021

b1rdex commented Dec 21, 2021

michaljusiega commented Dec 21, 2021

GuilhemN commented Dec 21, 2021

GuilhemN commented Dec 29, 2021

Upgrade Symfony 6.0 dependencies #1914

Upgrade Symfony 6.0 dependencies #1914

Conversation

fabianoroberto commented Nov 30, 2021

On this PR:

fabianoroberto commented Nov 30, 2021

dougetovski commented Dec 9, 2021 • edited Loading

fabianoroberto commented Dec 9, 2021

GuilhemN Dec 14, 2021 • edited Loading

Choose a reason for hiding this comment

fabianoroberto Dec 14, 2021

Choose a reason for hiding this comment

GuilhemN Dec 14, 2021 • edited Loading

Choose a reason for hiding this comment

fabianoroberto Dec 14, 2021

Choose a reason for hiding this comment

b1rdex Dec 21, 2021

Choose a reason for hiding this comment

b1rdex Dec 21, 2021

Choose a reason for hiding this comment

b1rdex commented Dec 21, 2021

michaljusiega commented Dec 21, 2021

GuilhemN commented Dec 21, 2021

GuilhemN commented Dec 29, 2021

dougetovski commented Dec 9, 2021 •

edited

Loading

GuilhemN Dec 14, 2021 •

edited

Loading

GuilhemN Dec 14, 2021 •

edited

Loading