Bring new features from Symfony 3/4/5/6 into our container

Created on 20 December 2018, over 5 years ago
Updated 22 July 2023, about 1 year ago

Problem/Motivation

In Symfony 3.3 the DependencyInjection component received a lot of attention and new features including autowiring and private services by default. Drupal's container and YamlFileLoader have not changed much since 8.0.0 and lack these new features. This means that:

  • We are steadily getting less and less like a Symfony application
  • Drupal developers have to type more and know more arcane Drupalisms and the internet is less helpful because the Symfony examples don't work
  • We risk becoming so incompatible that we won't be able to leverage Symfony container code

To read about the new features in Symfony 3.3 - https://symfony.com/doc/current/service_container/3.3-di-changes.html

Proposed resolution

Work on bring Drupal 8 the same or similar feature set:

Remaining tasks

Define all the tasks and discuss possibilities.

User interface changes

None

API changes

@todo

Data model changes

None

Release notes snippet

@todo

🌱 Plan
Status

Active

Version

11.0 πŸ”₯

Component
BaseΒ  β†’

Last updated 21 minutes ago

Created by

πŸ‡¬πŸ‡§United Kingdom alexpott πŸ‡ͺπŸ‡ΊπŸŒ

Live updates comments and jobs are added and updated live.
  • Needs framework manager review

    It is used to alert the framework manager core committer(s) that an issue significantly impacts (or has the potential to impact) multiple subsystems or represents a significant change or addition in architecture or public APIs, and their signoff is needed (see the governance policy draft for more information). If an issue significantly impacts only one subsystem, use Needs subsystem maintainer review instead, and make sure the issue component is set to the correct subsystem.

Sign in to follow issues

Comments & Activities

Not all content is available!

It's likely this issue predates Contrib.social: some issue and comment data are missing.

  • πŸ‡©πŸ‡ͺGermany donquixote

    Since we're adding interface aliases to core modules, would it make sense to start doing the same for contrib modules?

    To extend this question:

    I see for now, in core, we are keeping the string service ids, and are only adding interface names as aliases.
    For existing services this makes sense, because changing the existing service name would break BC.

    In symfony, it is possible to use a class name instead of a custom service id.
    This even seems to be the standard now, according to https://symfony.com/doc/current/service_container.html#creating-configur....

    Automatic Service Loading in services.yaml

    The documentation assumes you're using the following service configuration, which is the default config for a new project:

    So the question is, should we adopt or allow using class names as service names in our conventions for contrib and for new services in core, or should we stick to custom string ids?

  • πŸ‡«πŸ‡·France fgm Paris, France

    Beyond autowiring, we have a small issue in the URL generator not respecting the Unicode property of route regexps πŸ› Support Unicode regular expressions in routes, from Symfony 4.3 Active .

Production build 0.71.5 2024