-
-
Notifications
You must be signed in to change notification settings - Fork 907
Test and fix API Platform with Symfony 4.4 #3009
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
I think we will need this one as soon as possible :) |
e0d6bc8
to
24a7681
Compare
Bump'd, : Deprecations left to fix
|
We should target |
…:isMethodSafe() (dunglas) This PR was squashed before being merged into the 4.3 branch. Discussion ---------- [HttpFoundation] Allow to not pass a parameter to Request::isMethodSafe() | Q | A | ------------- | --- | Branch? | 4.3 | Bug fix? | yes | New feature? | no <!-- please update src/**/CHANGELOG.md files --> | Deprecations? | no <!-- please update UPGRADE-*.md and src/**/CHANGELOG.md files --> | Tickets | n/a | License | MIT | Doc PR | n/a This parameter was already deprecated in Symfony 4. Allowing to not pass it in Symfony 4.3 without triggering a deprecation allows to support both HttpFoundation 4.3 and 4.4, otherwise it's not possible. Needed to make API Platform compatible with Symfony 5 (api-platform/core#3009) Commits ------- e819256 [HttpFoundation] Allow to not pass a parameter to Request::isMethodSafe()
This PR was merged into the 4.4 branch. Discussion ---------- Re-allow to use "tagged" in service definitions | Q | A | ------------- | --- | Branch? | 4.4 | Bug fix? | no | New feature? | yes <!-- please update src/**/CHANGELOG.md files --> | Deprecations? | no <!-- please update UPGRADE-*.md and src/**/CHANGELOG.md files --> | Tickets | n/a | License | MIT | Doc PR | n/a Re-allow to use `tagged` in 4.4 and 5.0. It makes it easier for bundles to support both Symfony 4.3- and Symfony 4.4+. Needed to make API Platform compatible with Symfony 5 (api-platform/core#3009) Commits ------- 7b7dc0d Re-allow to use "tagged" in service definitions
Is it not possible to target |
It already targets 2.5. I just forgot to update this in the GitHub UI. |
624312d
to
885b6c7
Compare
@@ -84,7 +84,7 @@ public function getProjectDir() | |||
|
|||
protected function configureRoutes(RouteCollectionBuilder $routes) | |||
{ | |||
$routes->import("config/routing_{$this->getEnvironment()}.yml"); | |||
$routes->import(__DIR__."/config/routing_{$this->getEnvironment()}.yml"); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What is the reason for this change?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
A deprecation.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I can't find it in https://github.com/symfony/symfony/blob/4.4/UPGRADE-4.4.md and https://github.com/symfony/symfony/blob/4.4/src/Symfony/Component/Routing/RouteCollectionBuilder.php
Do you know which one it is?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't know, but it's related to resources, not to the routing directly.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
But it's so weird that we have to use an absolute path... :x
b008128
to
18b8841
Compare
There is one missing change to ensure compatibilty with Symfony 5: changing the even class names. |
To ensure forward compatibility with Symfony 5.0
Done and rebased. |
The last remaining failure with 4.4/5.0 is due to this Symfony issue: symfony/symfony#34220 In the meantime, we can allow failures for SF 4.4 or wait for this bug to be resolved. |
We should not merge this if there are still failing tests, IMO. |
So, we still have the last two failures related to CSV: https://github.com/api-platform/core/runs/285907674#step:14:67 |
I'm not able to reproduce the failures related to CSV locally anymore :| I restarted the test suite to see... |
Thanks @dunglas! 🎉 🚀 |
} | ||
|
||
if ('csv' === $request->getContentType()) { | ||
$context[CsvEncoder::AS_COLLECTION_KEY] = false; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is this really the right thing to do? Using CSV for a single item (as in the previously failing test) is actually very weird and makes little sense. See symfony/symfony#25218 (comment)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't see the problem, (a resource is a resource from REST point of view, and you can update it using any supported format, what would be weird is to be able to update some resources using a given format, but not some others). Anyway, we need this for BC.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The problem is that the CSV format does not lend itself to describing a single resource (as explained in the linked comment). Perhaps what we should do is to still set as_collection
to true
, but take the first item? WDYT?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Late to the party but @teohhanhui is correct, CSV is a collection of data items by definition. Forcing any posted CSV data to be processed as single data item leads to errors. (In our case triggered by a CSV import after a CSV export in API tests.)
So IMO this should be dropped or at least made configurable. For now we add a custom serializer context builder to unset this override.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Notice that this workaround broke due to #6186 adding an array shape for ApiPlatform\State\SerializerContextBuilderInterface::createFromRequest()
. Here CsvEncoder::AS_COLLECTION_KEY
(as_collection
) is not present which causes PHPStan to reject unsetting this key from the context. We worked around this by hinting the context to a plain array
instead:
public function createFromRequest(Request $request, bool $normalization, ?array $extractedAttributes = null): array
{
/** @var array */
$context = $this->decorated->createFromRequest($request, $normalization, $extractedAttributes);
unset($context[CsvEncoder::AS_COLLECTION_KEY]);
return $context;
}
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
can you open a new issue please?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Will do, but producing a minimal testcase for this will take a while.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
mhh but it's just a matter of phpstan type missing an &array<string, mixed>
? maybe a pr is enough
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Oh you mean the array shape. I thought it was about the $context[CsvEncoder::AS_COLLECTION_KEY] = false;
itself which is wrong from my POV.
Get rid offig/link-util
, use WebLink directly instead if available