test: Backed enum resource tests

[GwendolenLynch]

Q	A
Branch?	3.2
Tickets	#6264 #6279 #6283
License	MIT

@soyuka this is just an updated version of the tests I linked yesterday when discussing #6264 & #6279 … and if I m still wrong please just close this PR. 👍

These tests illustrate what was working for json, jsonhal, and jsonld formats, but breaks now with the change in symfony/symfony#54315

However, if a fix/workaround is found these tests will still add additional coverage for enum resources.

Notes:

• Tests pass when with:
  • core 3.2 as-of v3.2.19 (i.e. pre fix(graphql): increment graphql normalizer priority #6283)
  • symfony/framework-bundle <=7.0.5 (i.e. pre [Serializer] Fixed BackedEnumNormalizer priority for translatable enum symfony/symfony#54315)
• Missing jsonapi tests due to target branch (Derp! serializer !== schema factory)

[GwendolenLynch]

Symfony have merged #54484 so I've taken this out of draft.

I've added a conflict for 6.4.6 || 7.0.6 of symfony/framework-bundle and that should have core covered.

[soyuka]

I really like this but I won't be able to merge it right away as we need to work on the Hydra implementation. I reverted the priority change on our source code 2a87671

[soyuka]

Nice addition, API Platform supports enums only on properties for documentation via OpenAPI and using GraphQl but we did not add the support for RDF formats such as JSON-LD.
I started working on this (soyuka@48db6fa) but it needs more work. Currently it implements the context:

#[ApiResource(operations: [])] // An enum can't have operations so this needs to be fixed in he Metadata Factory
enum BackgroundColor: string
{
    case Sand = 'sand';
    case Magenta = 'magenta';
    case Teal = 'teal';
    case Blue = 'blue';
    case Mauve = 'mauve';

    /**
     * @return string[]
     */
    public static function values(): array
    {
        return array_column(self::cases(), 'value');
    }
}

My reference for the work is what's done on schema.org, for example:

https://schema.org/EnergyEfficiencyEnumeration

This is of type Enumeration and you can see it's "Enumeration members" at https://schema.org/EUEnergyEfficiencyEnumeration. When looking at the schema.org jsonld https://github.com/schemaorg/schemaorg/blob/main/data/releases/26.0/schemaorg-all-https.jsonld we find lots of examples:

{
      "@id": "schema:GamePlayMode",
      "@type": "rdfs:Class",
      "rdfs:comment": "Indicates whether this game is multi-player, co-op or single-player.",
      "rdfs:label": "GamePlayMode",
      "rdfs:subClassOf": {
        "@id": "schema:Enumeration"
      }
},

https://github.com/schemaorg/schemaorg/blob/c7dc8e5a3ad9f1e1645e282a18e46b5d2c19a657/data/releases/26.0/schemaorg-all-https.jsonld#L19759-L19767

And one of the value of the enum has this type:

{
      "@id": "schema:SinglePlayer",
      "@type": "schema:GamePlayMode",
      "rdfs:comment": "Play mode: SinglePlayer. Which is played by a lone player.",
      "rdfs:label": "SinglePlayer"
},

https://github.com/schemaorg/schemaorg/blob/c7dc8e5a3ad9f1e1645e282a18e46b5d2c19a657/data/releases/26.0/schemaorg-all-https.jsonld#L24689-L24694 (there are other values on this enum, just like for EnergyEfficiency).

So, for each value of the Backed Enum we should provide a given type to be referenced in the docs.jsonld.

[GwendolenLynch]

I reverted the priority change on our source code 2a87671

Suggestion on that, it is probably safe to revert the change to docs.feature as well.

Oh, and it is probably worth at least cherry-picking the composer change from here as that will prevent Symfony "broken" versions.

[GwendolenLynch]

I really like this but I won't be able to merge it right away as we need to work on the Hydra implementation.

No stress. I was more trying to get coverage for how it is now, as it is "in the wild" as far as use (I'm also guilty there) … supported or not.

[soyuka]

Suggestion on that, it is probably safe to revert the change to docs.feature as well.

Actually this is a bad test, I already picked the change on main (it's due to a property-info fix) and has no impact on the expected feature.

Suggestion on that, it is probably safe to revert the change to docs.feature as well.

I plan to do that indeed.

No stress. I was more trying to get coverage for how it is now, as it is "in the wild" as far as use (I'm also guilty there) … supported or not.

No problem we can work on integrating this, I'm afraid that it won't get into 3.3 as I'm already a month late on that release but it's definitely going to be a top priority for API Platform 3.4.
Anyways if you want to work on this feel free to do so, I'll see if I can in the upcoming weeks although I'll be afk for 3 weeks (except on weekends). I'll open a new PR with this test and my work for starters.

[soyuka]

this is probably correct, @dunglas could you review these tests?

[dunglas]

LGTM

[GwendolenLynch]

To catch future versions of some of the issues hit, I have added test for int and string enum resources, as well as GraphQL tests too.

The latter seems to have uncovered some internal-use of deprecated code in the GraphQL component.

Edit: GraphQL additions are based on https://gist.github.com/dunglas/f2e756725b1b842331dc8cdd38b4cc75

[soyuka]

let's target main or remove composer changes?

[GwendolenLynch]

Updated to main. There is no way to get --prefer-lowest to pass without these.

[soyuka]

but is this tight to enums?

[GwendolenLynch]

symfony/framework-bundle change seems to be not needed now the rest of the SF components are ^6.4 so I've dropped it.

symfony/phpunit-bridge is to include symfony/symfony#52844 which meant the tests just wouldn't run

Warning: The lock file is not up to date with the latest changes in composer.json. You may 
be getting outdated dependencies. It is recommended that you run `composer update` or 
`composer update <package name>`.
- Required package "symfony/phpunit-bridge" is not present in the lock file.

symfony/string is 100% about enums, and was the hardest to track down at the time. The change does mirror the constraint used in the component composer.json files.

[GwendolenLynch]

Anticipating the question "Why isn't CI failing?" (I had that question too), see this example from main yesterday:
https://github.com/api-platform/core/actions/runs/8679784849/job/23799224716?pr=6309

PHPUnit is not installed. Please run ./vendor/bin/simple-phpunit to install it

There seems to be a new-ish issue with CI set-up.

Originally I caught the failure on CI and then moved to local testing where it work correctly with 6.4.1+

[GwendolenLynch]

See #6113

[soyuka]

I want to bump to 6.4 for all dependencies (on main) but I need to do this in every components (needs a feature on the monorepo plugin) hopefully this is done this week

[soyuka]

Suggested change

	"symfony/phpunit-bridge": "^6.4.1 || ^7.0",
	"symfony/phpunit-bridge": "^6.4 || ^7.0",

[GwendolenLynch]

It will disappear on rebase when added to #6316 👍

[soyuka]

also we need to add the enum to the jsonld context, something like this:

    {
      "@id": "schema:CoOp",
      "@type": "schema:GamePlayMode",
      "rdfs:comment": "Play mode: CoOp. Co-operative games, where you play on the same team with friends.",
      "rdfs:label": "CoOp"
    },
{
      "@id": "schema:GamePlayMode",
      "@type": "rdfs:Class",
      "rdfs:comment": "Indicates whether this game is multi-player, co-op or single-player.",
      "rdfs:label": "GamePlayMode",
      "rdfs:subClassOf": {
        "@id": "schema:Enumeration"
      }
    },
    {
      "@id": "schema:SinglePlayer",
      "@type": "schema:GamePlayMode",
      "rdfs:comment": "Play mode: SinglePlayer. Which is played by a lone player.",
      "rdfs:label": "SinglePlayer"
    },

[soyuka]

tyvm @GwendolenLynch ! Looking forward to merging the enum feature next (I still need to try the branch and see what I can improve on the URI thing).