Thanks to visit codestin.com
Credit goes to github.com

Skip to content

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

Merged
merged 13 commits into from
Nov 4, 2019
Merged

Conversation

dunglas
Copy link
Member

@dunglas dunglas commented Aug 21, 2019

Q A
Bug fix? no
New feature? no
BC breaks? no
Deprecations? no
Tests pass? no
Fixed tickets n/a
License MIT
Doc PR n/a
  • Get rid of fig/link-util, use WebLink directly instead if available

@fabpot
Copy link

fabpot commented Oct 23, 2019

I think we will need this one as soon as possible :)

@soyuka soyuka force-pushed the test4.4 branch 3 times, most recently from e0d6bc8 to 24a7681 Compare October 23, 2019 14:33
@soyuka
Copy link
Member

soyuka commented Oct 23, 2019

Bump'd, :

Deprecations left to fix
Remaining self deprecation notices (10)

10x: The "twig.exception_listener" service is deprecated since Symfony 4.4.
1x in ApiTestCaseTest::testAssertJsonContains from ApiPlatform\Core\Tests\Bridge\Symfony\Bundle\Test
1x in ApiTestCaseTest::testAssertJsonContainsWithJsonObjectString from ApiPlatform\Core\Tests\Bridge\Symfony\Bundle\Test
1x in ApiTestCaseTest::testAssertJsonContainsWithJsonScalarString from ApiPlatform\Core\Tests\Bridge\Symfony\Bundle\Test
1x in ApiTestCaseTest::testAssertJsonEquals from ApiPlatform\Core\Tests\Bridge\Symfony\Bundle\Test
1x in ApiTestCaseTest::testAssertJsonEqualsWithJsonObjectString from ApiPlatform\Core\Tests\Bridge\Symfony\Bundle\Test
1x in ApiTestCaseTest::testAssertJsonEqualsWithJsonScalarString from ApiPlatform\Core\Tests\Bridge\Symfony\Bundle\Test
1x in ApiTestCaseTest::testAssertMatchesJsonSchema from ApiPlatform\Core\Tests\Bridge\Symfony\Bundle\Test
1x in ApiTestCaseTest::testAssertMatchesResourceCollectionJsonSchema from ApiPlatform\Core\Tests\Bridge\Symfony\Bundle\Test
1x in ApiTestCaseTest::testAssertMatchesResourceItemJsonSchema from ApiPlatform\Core\Tests\Bridge\Symfony\Bundle\Test
1x in ApiTestCaseTest::testFindIriBy from ApiPlatform\Core\Tests\Bridge\Symfony\Bundle\Test

Remaining direct deprecation notices (1)

1x: The "Doctrine\Bundle\DoctrineBundle\Registry" class implements "Symfony\Bridge\Doctrine\RegistryInterface" that is deprecated since Symfony 4.4, use Doctrine\Common\Persistence\ManagerRegistry instead.
1x in ApiTestCaseTest::testAssertJsonContains from ApiPlatform\Core\Tests\Bridge\Symfony\Bundle\Test

Remaining indirect deprecation notices (4)

4x: Loading the file "config/routing_test.yml" from the global resource directory "/home/soyuka/forks/coreb/tests/Fixtures/app" is deprecated since Symfony 4.4 and will be removed in 5.0.
1x in ApiTestCaseTest::testAssertJsonContains from ApiPlatform\Core\Tests\Bridge\Symfony\Bundle\Test
1x in ApiTestCaseTest::testAssertJsonContainsWithJsonObjectString from ApiPlatform\Core\Tests\Bridge\Symfony\Bundle\Test
1x in ApiTestCaseTest::testAssertJsonContainsWithJsonScalarString from ApiPlatform\Core\Tests\Bridge\Symfony\Bundle\Test
1x in ApiTestCaseTest::testAssertMatchesJsonSchema from ApiPlatform\Core\Tests\Bridge\Symfony\Bundle\Test

@teohhanhui
Copy link
Contributor

We should target 2.5 instead, just like how we provided Symfony 4.3 compatibility in API Platform 2.4

nicolas-grekas added a commit to symfony/symfony that referenced this pull request Oct 29, 2019
…: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()
nicolas-grekas added a commit to symfony/symfony that referenced this pull request Oct 29, 2019
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
@teohhanhui
Copy link
Contributor

teohhanhui commented Oct 29, 2019

Is it not possible to target 2.5 instead? (And perhaps a separate PR to bump the dependencies in master to reduce maintenance burden?) I think it'd be very valuable for 2.5 to be compatible with Symfony 4.4 (if not 5.0).

@dunglas
Copy link
Member Author

dunglas commented Oct 29, 2019

It already targets 2.5. I just forgot to update this in the GitHub UI.

@dunglas dunglas changed the base branch from master to 2.5 October 29, 2019 15:40
@teohhanhui teohhanhui force-pushed the test4.4 branch 4 times, most recently from 624312d to 885b6c7 Compare October 30, 2019 16:05
@@ -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");
Copy link
Contributor

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?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

A deprecation.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Copy link
Member Author

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.

Copy link
Contributor

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

@fabpot
Copy link

fabpot commented Nov 1, 2019

There is one missing change to ensure compatibilty with Symfony 5: changing the even class names.

@teohhanhui
Copy link
Contributor

Done and rebased.

@dunglas
Copy link
Member Author

dunglas commented Nov 2, 2019

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.

@teohhanhui
Copy link
Contributor

We should not merge this if there are still failing tests, IMO.

@teohhanhui
Copy link
Contributor

So, we still have the last two failures related to CSV: https://github.com/api-platform/core/runs/285907674#step:14:67

@dunglas
Copy link
Member Author

dunglas commented Nov 3, 2019

I'm not able to reproduce the failures related to CSV locally anymore :| I restarted the test suite to see...

@dunglas dunglas merged commit b47ccea into api-platform:2.5 Nov 4, 2019
@dunglas dunglas deleted the test4.4 branch November 4, 2019 03:58
@teohhanhui
Copy link
Contributor

Thanks @dunglas! 🎉 🚀

}

if ('csv' === $request->getContentType()) {
$context[CsvEncoder::AS_COLLECTION_KEY] = false;
Copy link
Contributor

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)

Copy link
Member Author

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.

Copy link
Contributor

@teohhanhui teohhanhui Nov 5, 2019

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?

Copy link
Contributor

@mbrodala mbrodala Apr 8, 2022

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.

Copy link
Contributor

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;
    }

Copy link
Member

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?

Copy link
Contributor

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.

Copy link
Member

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

Copy link
Contributor

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants