[META] Symfony 4.0 compatibility

Since this would also cause a BC break for any contrib modules using symfony APIs, should this target 9.x instead?

We intend to stay on 3.4.x until 2021

4.x is 9.0 territory

Active cos now it is 9.x-dev there is nothing to stop people working on something that will not get momentum for a few years :)

What about compatibility layer?
There is good analysis here
https://drupalize.me/blog/201802/symfony-4-and-drupal

A compromise in between now and D9 could be that core uses only non deprecated features from Symfony 3.4, allowing local installations to upgrade seamlessly to 4.0 by allowing it per composer.json requirements, while still be packaged per default with 3.4. This way, there's no BC break in core, but developers can choose to upgrade (and potentially BC break for contrib modules). This would mean that the test bots should tests with both 3.4 and 4.0 (or 4.1) using a more complex test matrix (for core at least).

Interesting :
New in Symfony 4.1: Fastest PHP Router
New in Symfony 4.1: Internationalized routing

Drupal 8 has its own router, I'm not sure those optimizations will hit Drupal core.

I hope to speak only constructively,

But if we control the router design, should we start a new issue investigating what we can do to copy over at least some of the router improvements?

-- while keeping backwards compatibility
-- and forwards compatibility as I expect D9 to employ Symfony 4.x routing

As I understand it routing a common bottleneck for Drupal sites and the fastest PHP router link in #8 is making statements that are worth looking into at least.

Symfony 4.1 URL matching is 77 times faster than in previous Symfony versions

But if we control the router design, should we start a new issue investigating what we can do to copy over at least some of the router improvements?

A lot of SF4 router improvements (at least considering the performance side of things) is done by better regex matching on the routes. If I remember well, D8 has a model where it uses a router table and does an SQL query to find the route - if that's still the case, those performance improvements cannot be ported, just because they don't work way the same at all.

Anyway I don't think that routing is a bottleneck to Drupal, it's efficient already, and even if the router is 77% faster, it would probably NOT be significant at all in Drupal which is a lot more complex than a baremetal Symfony skeleton application.

Anyway I don't think that routing is a bottleneck to Drupal, it's efficient already, and even if the router is 77% faster, it would probably NOT be significant at all in Drupal which is a lot more complex than a baremetal Symfony skeleton application.

I get what you mean but optimizing each part a bit can add up and routing is probably one of the most important parts specially for headless apps. Also symfony generates those regexes, Drupal can do the same, can work sort of like cache.
But we all know getting something like this into core can take several years! so maybe this idea is better suited for contrib module or a core experimental module

Thanks for all the responses, every point valid. We are expecting Drupal to be a swiss army knife for all solutions and so it will always be complicated.

I was thinking about headless solutions ... and how some sample/template solutions are inserting a node [javascript framework ] caching service between Drupal8 core and the servers point of presence on the web.

I don't want to animate anyone further so I guess the challenge is if I can see a way forward .. and some small specific routes could be enhanced and I should provide performance test runs to support my claim in a separate issue.

Thanks pounard and sinasalek for talking this through.

Yes, routing performance improvements are a side topic of the main one, which is upgrading to Symfony 4, as I stated upper, for 8.x it would be nice to have core compatibility (but still packaged per default with 3.x) and allow users installing via composer to explicitly upgrade to 4.x.

Retitling and moving back to Drupal 8.

We should at least do the following:

1. Identify all the deprecated code that Drupal 8 relies on and update for it, opening issues for anything not straightforward

2. Have an issue with a patch that updates to Symfony 4 so we can see if it passes or not.

3. Potentially, relax our composer.json requirements to allow Symfony 4 to be installed, once the above two are done, if it's feasible to do so.

Also bumping to critical since this blocks opening Drupal 9 and needs to be done before Symfony EOL at the end of 2021.

1. we have #2959269: [meta] Core should not trigger deprecated code except in tests and during updates for that for example.

Updating the IS. Also this is meta-y.

Woot! meta-time!

Might as well include the Serializer enhancements : https://symfony.com/blog/new-in-symfony-4-1-serializer-improvements .

Nothing earth-shattering but it would be good to know if we have run into the issues this solves.

In response to

#15.2. Have an issue with a patch that updates to Symfony 4 so we can see if it passes or not.

As a pipe cleaning exercise I want to relax all Symfony version numbers to "*" and see what shakes.
.. so I have spawned a side issue .. It is highly speculative and far for the last word on the subject of how we respond to Symfony4 but we may flush out bugs

One of the most Symfony 4 feature I like, is "Automatic Service Loading in services.yaml". The successor of auto-wiring, which goes a step further. After switching to PHP 7.1, next step would be to reconfigure the services.yaml files and ditching a lot of service declarations, which can be saved then.

I strongly recommend that for core services explicit dependencies should be kept in yaml files. Auto-wiring is not magic, and explicit is better if you don't want to have any bad surprises. But auto-wiring then is very nice for the application you build on top of it, it's a great tool for the final developer.

Auto-wiring is not magic, and explicit is better

I am not expressing an opinion one way or the other

In the spirit of cooperation, I would like to challenge the idea and say that by definition auto-wiring must always be explicit

taking one common definition from core service.yml -- which we can delete

renderer:
class: Drupal\Core\Render\Renderer
arguments: ['@controller_resolver', '@theme.manager', '@plugin.manager.element_info', '@render_placeholder_generator', '@render_cache', '@request_stack', '%renderer.config%']

in the auto-wiring case the constructor would have Drupal\Core\Render\Renderer injected as a parameter

..
use Drupal\Core\Render\Renderer
..

   public function __construct(Render $render ....) { ... }

-- which because the namespace is unique then the services is uniquely defined.

BUT there are also more complex definitions such as

    logger.channel.image:
    parent: logger.channel_base
    arguments: ['image']

Where arguments are used to deviate from a parent service ... we will still need to "manually add" / keep a entry in a core.service.yml.. here are the symfony docs.

see https://symfony.com/doc/current/service_container.html#services-manually...

Also we will need to keep definitions in a core.service.yml like file for injection of things like EntityTypeManagerInterface -- so that we can relate a interface to a concrete class.

In short core.services.yml will be with us in one form or another for a long time but we can strip it down so that is it faster to read and has less code to maintain.

Anyway I hope this helps.

Indeed, you make a very valid point. core.services.yml is terribly bloated, I have to admit that anythings that reduces it would be good.

As per @dries blog, should we put back this to 9.x?

There's plenty of work can be done before the 9.x branch opens.

#2976394: Allow Symfony 4.4 to be installed in Drupal 8 is open and we nearly have a green patch there.

We'll need to split out some of the fixes there to separate issues, and make the code work with both Symfony 3 and Symfony 4.

Then we can look at relaxing our composer.json to allow Drupal 8 to be installed with Symfony 4. #2874198: Create and run dependency regression tests for core will help a lot with that.

And once that's done, this could theoretically allow contrib to test against a Drupal 8 build with Symfony 4 too.

Then when Symfony 5 is released in November 2019, we can try to do the same thing all over again.

Ideally when 9.x opens up, we're left with disallowing installing with Symfony 3 in composer.json and deciding whether to default to Symfony 4 or 5 in packaging.

So #2976394: Allow Symfony 4.4 to be installed in Drupal 8 has a complete patch to update to Symfony 4 now pretty much (including fixes). What is the difference between that and this one then? Should that be a child of this one and that spawn more children of this one? Or should this be closed in favor of that one and that made a meta to be broken out to more issues?

Looking at this issue summary, #2976394: Allow Symfony 4.4 to be installed in Drupal 8 covers the tasks listed no?

I think that issue needs to be split into multiple children of this issue (classloader replacement, minor test changes, a new issue to talk about the Symfony 4 container etc.)

We also need an issue to relax our composer.json requirements so that Drupal 8 projects can use Symfony 4 if they want to, might be blocked on the min/max testing issue #2976407: Use drupalci.yml for composer dependency min/max testing - DO NOT COMMIT. If we can do that, we'll be able to pick up failures with the next couple of Symfony 4 minor releases too.

Also need to go through this all again with Symfony 5 in almost exactly one year.

Opened #3009219: Update Symfony to 4.4 in Drupal 9.0 to cover what needs to be done eventually in Drupal 9 once Drupal 8 is prepared to support Symfony 4, at least in an ideal scenario where only the dependency version change would be updated in that. That issue needs all the work here.

Since the child issues of this are individually critical, downgrading this to normal. We still have Symfony 4.3 and Symfony 4.4 to account for when they're released, so this can stay open to attach new issues to.

A new issue just appeared in Symfony 4.3: the HttpClient component will probably have to become a supported alternative to Guzzle, as it brings the significant advantage of non-blocking behavior.

https://symfony.com/blog/new-in-symfony-4-3-httpclient-component

@fgm: we definitely need to figure out the support timeline of Guzzle as well as some people said they may go unsupported following the integration of this HTTP client in Symfony. There does not seem to be any official communication about this on the Guzzle website though. Can you open a dedicated issue? Thanks!

@Gábor Hojtsy : followup created at #3063005: Support a possible switch from Guzzle to Symfony HTTP Client.

Found an earlier issue about this #3047294: Switch to symfony/http-client better use it since it already had some discussion;

The parent of this at #3009219: Update Symfony to 4.4 in Drupal 9.0 and ongoing children at #2976394: Allow Symfony 4.4 to be installed in Drupal 8 should be covering all outstanding parts of this issue. Closing as duplicate of those and will reparent #2976394: Allow Symfony 4.4 to be installed in Drupal 8.