Skip to content
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

Attempting Symfony 4 support #300

Merged
merged 13 commits into from
Dec 13, 2017
Merged

Conversation

weaverryan
Copy link
Contributor

Hi guys!

This adds Symfony 4 support. I'm not sure if any changes to the code are needed, let's run the tests and find out!

Cheers!

@tobias-93
Copy link
Collaborator

Hi @weaverryan,

It would certainly be nice if we can support SF4!
Could you add Travis config to test this?
I also see that some tests are failing due to some JS error, will have a look at that later on.

@tobias-93
Copy link
Collaborator

@weaverryan I have fixed the tests for the current master, so you should be able to see what's going on if you add the required Travis config.

@ElectricMaxxx
Copy link

Anything going on here?

@weaverryan
Copy link
Contributor Author

Haha, yep. I forgot about this for a few days! But I (probably) just finished it:

  • composer.json now supports Symfony 4
  • tests now run Symfony 4
  • Symfony 2.3 support was dropped, which made fixing the 1 test failure on Symfony 4 quite easy
  • Any public services were explicitly marked as public="true" so that they remain public in Symfony 4

So, no behavior changes or BC breaks, and the bundle (assuming the tests do pass) is now Symfony 4 compat!

@@ -23,18 +26,23 @@
*
* @author William DURAND <william.durand1@gmail.com>
*/
class RouterDebugExposedCommand extends RouterDebugCommand
class RouterDebugExposedCommand extends ContainerAwareCommand
Copy link
Contributor Author

Choose a reason for hiding this comment

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

RouterDebugCommand became final in Symfony 3.4. But we only extended it for Symfony 2.3 support. So, it was an easy win to stop extending it.

new InputOption('show-controllers', null, InputOption::VALUE_NONE, 'Show assigned controllers in overview'),
new InputOption('format', null, InputOption::VALUE_REQUIRED, 'The output format (txt, xml, json, or md)', 'txt'),
new InputOption('raw', null, InputOption::VALUE_NONE, 'To output raw route(s)'),
))
Copy link
Contributor Author

Choose a reason for hiding this comment

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

These are a copy of the options that the previous parent class added for us.

@weaverryan
Copy link
Contributor Author

Tests pass! This should be ready for merge and a new release to make it available :)

@@ -17,6 +19,7 @@ cache:
- $HOME/.composer/cache/files

before_install:
- if [ "$DEPENDENCIES" = "beta" ]; then composer config minimum-stability beta; fi;

Choose a reason for hiding this comment

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

General question: what is better? require ^4.0@dev and doing a minimum-stability: dev here, or going explicit on beta to catch releases only?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

It's a great question :). I chose to do beta because I don't think it makes sense to always test against the latest (effectively dev-master) version of Symfony. We don't really care of the bundle is compatible with a new Symfony version until it becomes beta at least. So I think this is the best config.

Choose a reason for hiding this comment

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

But we would have to change twice:

  • from beta to RC
  • from RC to stable
    having dev for that period of try and fail would cause only one change then: from dev -> stable.
    But i think the point of having released versions only sounds valid.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I don't think we would need to change this again. This is the minimum stability, so I think when 4.0.0 stable is released, this line would cause 4.0.0 to be downloaded. This should say "use the latest beta, RC or stable version".

Copy link

@ElectricMaxxx ElectricMaxxx left a comment

Choose a reason for hiding this comment

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

Just a minor issue.

composer.json Outdated
"symfony/serializer": "~2.3||~3.0",
"symfony/console": "~2.3||~3.0",
"php": ">=5.3.9",
"symfony/framework-bundle": "~2.7||~3.0|^4.0",

Choose a reason for hiding this comment

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

why ~ 2.7 and not 2.8 as the LTS?

Choose a reason for hiding this comment

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

@weaverryan
Copy link
Contributor Author

Comments addressed!

@weaverryan
Copy link
Contributor Author

@tobias-93 This should be ready. Someone at the hack day has been using/testing this bundle on Symfony 4 with no issues. So beyond the tests passing, I think it should be good :). I'm told this is blocking doctrine/phpcr-bundle Symfony 4 support - the merge+tag will fix that.

Thanks!

@tobias-93
Copy link
Collaborator

Hi @weaverryan,

It looks good to me, thank you for your work!
However, I do not agree with dropping support for SF 2.7.
As you can see on http://symfony.com/roadmap?version=2.7#checker, it will still be supported for more than 1 year and I think we should do so too, especially because we're not running into any BC conflicts with it.
Could you revert your latest commit?

Thanks!

@alexchuin
Copy link

Symfony 4.0 is here! Thanks guys 👍

.travis.yml Outdated
@@ -8,6 +8,8 @@ matrix:
- php: 7.1
- php: 7.1
env: SYMFONY_VERSION='2.8.*'
Copy link
Member

Choose a reason for hiding this comment

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

Please do 2 additional things:

  • add testing on PHP 7.2
  • add a job forcing testing on the 3.4 LTS, similar to this 2.8 job

Copy link
Member

Choose a reason for hiding this comment

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

agreed

@@ -23,18 +26,23 @@
*
* @author William DURAND <william.durand1@gmail.com>
*/
class RouterDebugExposedCommand extends RouterDebugCommand
class RouterDebugExposedCommand extends ContainerAwareCommand
Copy link
Member

Choose a reason for hiding this comment

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

This command has to be defined as a service, otherwise it won't be registered in Symfony 4.

And once defining it as a service, we can use DI in it instead of making it ContainerAware, allowing to avoid making the extractor service public (it is public only because of this command being ContainerAware)

Copy link
Member

Choose a reason for hiding this comment

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

and commands as services were supported in 2.7 already https://symfony.com/doc/2.7/console/commands_as_services.html

@stof
Copy link
Member

stof commented Dec 1, 2017

and I agree with @tobias-93 about keeping support for the 2.7 LTS, giving that there is no cost for it at all (we don't have any BC layer for 2.7 support)

@ElectricMaxxx
Copy link

@weaverryan can we try to finish this one here?

composer.json Outdated
"symfony/framework-bundle": "~2.3||~3.0",
"symfony/serializer": "~2.3||~3.0",
"symfony/console": "~2.3||~3.0",
"php": ">=5.3.9",
Copy link
Member

Choose a reason for hiding this comment

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

should we not also fix the php dep to state the major version explicitly?

composer.json Outdated
"symfony/serializer": "~2.3||~3.0",
"symfony/console": "~2.3||~3.0",
"php": ">=5.3.9",
"symfony/framework-bundle": "~2.8||~3.0|^4.0",
Copy link
Member

Choose a reason for hiding this comment

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

as stated else where .. imho we should keep 2.7 allowed

weaverryan and others added 6 commits December 2, 2017 13:24
RouterDebugCommand

RouterDebugCommand became final in Symfony 3.4. But it was only
extended for 2.3 support anyways.
... so that they remain public in Symfony 4.0
@weaverryan
Copy link
Contributor Author

Thanks for the feedback guys! And sorry for the delay - I lost track of this PR.

I've just made the updates... but my final update caused a conflict. I'll have to look later - the baby is awakening!

@weaverryan
Copy link
Contributor Author

Ha! Nevermind, I finished just in time! Feedback warmly welcome - I'm taking care of everything I'm know of, but I don't know the internals of the bundle super well :).

@lsmith77
Copy link
Member

lsmith77 commented Dec 3, 2017

home stretch! DumpCommandTest::testExecuteFormatOption() still needs to be refactored to remove the container

@weaverryan
Copy link
Contributor Author

I don't know how I missed that :). Let's try one more time

@tobias-93
Copy link
Collaborator

tobias-93 commented Dec 4, 2017

@weaverryan good work! I see the tests fail because of a deprecation notice existing in PHP 7.2. The deprecated code seems to be in the source of PHPUnit itself (although I cannot test this myself because I have no machine with PHP 7.2 available) and was fixed in a later version. Could you update the version of PHPUnit in the phpunit-script from 6.0 to 6.5? That should include the non-deprecated code.

@tobias-93
Copy link
Collaborator

@weaverryan I like skipping the local phpunit script and just using the Symfony PHPunit-bridge script (which was used anyway with some specific configuration).
Could you adjust the docs and remove the phpunit script?
Then I think this is ready to be merged!

@lsmith77 lsmith77 self-requested a review December 4, 2017 16:26
@lsmith77
Copy link
Member

lsmith77 commented Dec 4, 2017

@stof I think your concerns have been addressed

@tobias-93 tobias-93 mentioned this pull request Dec 5, 2017
@tobias-93
Copy link
Collaborator

@weaverryan In the end I think the directory configuration was made for a reason, and it's nice that an error message is shown if someone didn't run composer update. I therefore reverted your last commit and fixed the phpunit script. I think this is ready to be merged now.

@weaverryan
Copy link
Contributor Author

I'm fine with that - we can discuss it in another PR. simple-phpunit has a few advantages (like reporting deprecations), but it's certainly out of scope.

So, let's merge!!!

"symfony/framework-bundle": "~2.3||~3.0",
"symfony/serializer": "~2.3||~3.0",
"symfony/console": "~2.3||~3.0",
"php": "^5.3.9|^7.0",
Copy link
Member

Choose a reason for hiding this comment

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

not sure if we still want to support versions below 5.6 .. but if its no extra effort, I guess its fine.

Copy link
Member

Choose a reason for hiding this comment

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

if it works, let's keep it and once it causes an issue, one can increase the min version?

Copy link
Member

Choose a reason for hiding this comment

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

👍

Copy link
Collaborator

@tobias-93 tobias-93 Dec 8, 2017

Choose a reason for hiding this comment

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

It is in line with the rest of our dependencies, so it makes sense to only increase this if we want to use features present in PHP >5.3.

@tobias-93
Copy link
Collaborator

simple-phpunit has a few advantages (like reporting deprecations)

If you look carefully, our own phpunit-script does nothing more than check if simple-phpunit is present and set the working directory, before starting simple-phpunit to do the 'real' work 😉. So no change is needed, really.

private $targetPath;

/**
* @var \FOS\JsRoutingBundle\Extractor\ExposedRoutesExtractorInterface

Choose a reason for hiding this comment

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

@var ExposedRoutesExtractorInterface is enough as you imported the namespace?

private $extractor;

/**
* @var \Symfony\Component\Serializer\SerializerInterface

Choose a reason for hiding this comment

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

@var SerializerInterface is enough as you imported the namespace?

{
protected static $defaultName = 'fos:js-routing:debug';

private $extractor;

Choose a reason for hiding this comment

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

Maybe add PHPDocs

@weaverryan
Copy link
Contributor Author

Ping! Who can merge this and tag a release. Is it you @tobias-93? Any issues left?

@tobias-93 tobias-93 merged commit 9334e8f into FriendsOfSymfony:master Dec 13, 2017
@tobias-93
Copy link
Collaborator

@weaverryan Thank you for your effort, I've merged the changes!

@tobias-93
Copy link
Collaborator

I've tagged the 2.1.0 release for your convenience

@weaverryan weaverryan deleted the patch-1 branch December 13, 2017 13:25
@weaverryan
Copy link
Contributor Author

That's perfect! Thanks so much! :D

@lsmith77
Copy link
Member

thank you @weaverryan !

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.

9 participants