Allow installation with Symfony 8

[alexander-schranz]

Prepare the Bundle for Symfony 8 release.

[alexander-schranz]

the class is already marked as @internal and sowe can add the required return type without breaking any bc promises.

[stof]

Note that to support Symfony 8 fully, you will also need to add support for Symfony 8 in the extensions themselves (they use symfony/cache and symfony/string)

[stof]

Isn't it necessary to add an actual return type in the compiler passes as well ?

[alexander-schranz]

@stof

Note that to support Symfony 8 fully, you will also need to add support for Symfony 8 in the extensions themselves (they use symfony/cache and symfony/string)

Make sense.

Isn't it necessary to add an actual return type in the compiler passes as well ?

Good hint, I added minimal test cases to catch it in future upgrades, are you fine with them?

[stof]

@alexander-schranz please rebase your branch to fix conflicts in the composer.json. I tried doing it but GitHub rejected my push to your branch (despite the UI saying that this PR allows edits by maintainers).

[alexander-schranz]

Rebased. PHPStan issues are related to symfony/symfony#62616 lets wait for response there.

[alexislefebvre]

What about ignoring these PHPStan issues? 🫣

Let’s say we add rules to ignore these issues in this repo, would these errors also appear in projects that rely on this bundle?

I really like PHPStan but I think that publishing a release – to allow end-users to upgrade their dependencies – is more important than static analysis. This is true only if ignoring this error would not create a cascade of errors in projects that use this bundle.

[alexander-schranz]

@stof symfony/symfony#62616 is merged. The CI would be get green as soon as that is released. Can currently be tested with composer config minimum-stability dev before running composer update.

[doudoustephane]

@stof symfony/symfony#62616 is merged. The CI would be get green as soon as that is released. Can currently be tested with composer config minimum-stability dev before running composer update.

I can't find a way to require your branch "patch-1" in my SF8 inpiste of the minimum stability and the composer repository declaration.

{ "type": "vcs", "url": "https://github.com/alexander-schranz/StofDoctrineExtensionsBundle.git" },

Is there anything special i'm missing to avoid to be stuck waiting the release ?
Thanks

[Chris53897]

There is a Dev run https://github.com/stof/StofDoctrineExtensionsBundle/actions/runs/19956359483/job/57226196540?pr=516
But to use it in production, we should wait for a stable release with symfony 8 support of
https://github.com/doctrine-extensions/DoctrineExtensions/releases

The phpstan would be green too if we add this. But i think it not needed, as symfony 8.0.1 will probably not take long to be released.

/**
     * TODO can be removed after Symfony 8.0.1 is released
     * @return TreeBuilder<'array'>
     */

[doudoustephane]

Thank you @Chris53897 , i understand that's not already available in production, that's why i'm trying to use the "dev-patch-1" composer requirement but it can't find it.
So that's my question about why the branch can't be read by composer waiting the production ready release.

[stof]

@doudoustephane the patch-1 branch is in a fork, not in the main repo. So packagist.org does not know about the dev-patch-1 version.

[doudoustephane]

@doudoustephane the patch-1 branch is in a fork, not in the main repo. So packagist.org does not know about the dev-patch-1 version.

Even if i specified the repository entry point ?
I've done as it with a fork on another packagist repo

[alexander-schranz]

also composer does not resolve dependencies against a fork branch. It resolve against default branch and does then checkout the given branch, so no symfony 8 there. So be patient currently you need wait until things are merged.

[doudoustephane]

Okay, that explains things so, thank you to all for your answers

[stof]

lso composer does not resolve dependencies against a fork branch. It resolve against default branch and does then checkout the given branch, so no symfony 8 there. So be patient currently you need wait until things are merged.

this is not true. Branches are loaded as versions properly in composer (otherwise, we would not be able to have different dependencies in different versions of Symfony which would be insane).
I think you are confusing things with the commit-pinning hack instead.

[NickMous]

@doudoustephane What you need to do to get this branch to work locally is the following:

KEEP IN MIND, THIS IS A TEMPORARY HACK

In your composer.json, add the following to the repositories section:

    "repositories": [
        {
            "type": "package",
            "package": {
                "name": "stof/doctrine-extensions-bundle",
                "version": "dev-symfony8",
                "source": {
                    "type": "git",
                    "url": "https://github.com/alexander-schranz/StofDoctrineExtensionsBundle.git",
                    "reference": "patch-1"
                },
                "autoload": {
                    "psr-4": {
                        "Stof\\DoctrineExtensionsBundle\\": "src/"
                    }
                }
            }
        }
    ],

Then, to use the package:

composer require stof/doctrine-extensions-bundle:dev-symfony8 gedmo/doctrine-extensions

If you don't have symfony flex, add the bundle just like the docs say.

Then in your doctrine.yml:

doctrine:
    orm:
        mappings:
            gedmo_translatable:
                type: attribute
                prefix: Gedmo\Translatable\Entity
                dir: "%kernel.project_dir%/vendor/gedmo/doctrine-extensions/lib/Gedmo/Translatable/Entity"
                alias: GedmoTranslatable # (optional) it will default to the name set for the mapping
                is_bundle: false
            gedmo_translator:
                type: attribute
                prefix: Gedmo\Translator\Entity
                dir: "%kernel.project_dir%/vendor/gedmo/doctrine-extensions/lib/Gedmo/Translator/Entity"
                alias: GedmoTranslator # (optional) it will default to the name set for the mapping
                is_bundle: false
            gedmo_loggable:
                type: attribute
                prefix: Gedmo\Loggable\Entity
                dir: "%kernel.project_dir%/vendor/gedmo/doctrine-extensions/lib/Gedmo/Loggable/Entity"
                alias: GedmoLoggable # (optional) it will default to the name set for the mapping
                is_bundle: false
            gedmo_tree:
                type: attribute
                prefix: Gedmo\Tree\Entity
                dir: "%kernel.project_dir%/vendor/gedmo/doctrine-extensions/lib/Gedmo/Tree/Entity"
                alias: GedmoTree # (optional) it will default to the name set for the mapping
                is_bundle: false

This is how far I have gotten, now to configure the rest...

[stof]

@NickMous using a package repository does not make sense. You have to duplicate the whole composer.json (your snippet misses the requirements btw). You should use vcs to use the composer.json file from the git repo.

[NickMous]

@stof Somehow when I did that, it didn't work, I only got errors from composer

[doudoustephane]

@stof Somehow when I did that, it didn't work, I only got errors from composer

I have the same problem, that's why i asked my first message too.
I'll have a try to your solution.
@stof i know that's an ugly solution but i need it to unblocked me on the project.
I'll reset it to the good way until making the first release of my project, when releases will be made :)

[ltlsquare]

Is there any additional help needed to get this one over the line?

[doudoustephane]

Is there any additional help needed to get this one over the line?

Not on my side, i came back the project to SF 7.4 and i'll see in a few weeks when SF8 will be stabilized

[alexander-schranz]

CI green now 🟢

[alexander-schranz]

Still doctrine-extensions/DoctrineExtensions#3008 requires also a tag before.