Are Twig services part of your public API?

Created on 2 June 2025, 10 days ago

Problem/Motivation

Hi, much ❤️ for the module!

Sometimes I find myself wanting to factor something using a twig tweak feature out of a theme template and into a preprocess (still within the theme), typically because it's used in multiple templates. Sometimes it's convenient to do that by rewriting the code without Twig Tweak, but sometimes I just directly call the same service that the Twig function/filter uses.

Do you view the various Twig services accessible in PHP as part of your public API, or just how they're exposed to Twig?

If they're not, it might make sense to explicitly mark them @internal; otherwise it might be nice to add interfaces.

Thanks!

Steps to reproduce

Proposed resolution

Remaining tasks

User interface changes

API changes

Data model changes

💬 Support request
Status

Active

Version

4.0

Component

Code

Created by

🇬🇧United Kingdom AndyF

Live updates comments and jobs are added and updated live.
Sign in to follow issues

Comments & Activities

  • Issue created by @AndyF
  • 🇷🇺Russia Chi

    The Twig Tweak services are part of public API which means their signature and behavior will not change withing till the next major release. However, in 4.x they will be final, you won't be able to extend them. That work is in progress.
    As of interfaces, I don't think it is needed. The primary use of interfaces is defining an abstraction, so the services can be easily swapped with different implementation. Twig Tweak services are only used in various Twig functions and filters. And it much easy to just replace those functions and filters using alter hook than swapping inner service.

  • 🇬🇧United Kingdom AndyF

    Beautiful, thanks for the confirmation!

    The primary use of interfaces is defining an abstraction, so the services can be easily swapped with different implementation.

    Right you are (: I think I misread the lack of interfaces as a signal that they might not be public, no point bloating things unnecessarily, thanks again!

  • 🇬🇧United Kingdom AndyF

    Although just idly thinking out loud, if there's no anticipation of swapping out services via the container, does it make sense not to have them as services at all and just use the class resolver? Not sure you win much, feels a bit like navel-gazing, but popped into my head (:

  • 🇷🇺Russia Chi

    Using the service container seems more continent for injecting dependencies and testing.

  • 🇬🇧United Kingdom AndyF

    Understood, thanks for humoring and learnin me (:

Production build 0.71.5 2024