What would you like to see as major changes that would lead to a BC break for the next major release of Twig?

[fabpot]

We've started working on the next major Twig release. As announced last year, this new version will probably land under the Symfony mono-repository.

For the first time in Twig history, I'd like to fix the major issues that would be BC breaks and that we've never done.

This issue acts as a community wish list for things you want to see in the next major version that could lead to BC breaks (hint: like operators precedence).

Feel free to comment and vote.

[nsetyo]

I really like the askama approach to make template type safe, and a little out of topic, it would be great if twig had an up-to-date formatter (maybe with a prettier plugin maintained by core team)

[GromNaN]

I like that you started removing usage of echo and ob_* in #3950. That's a breaking change if some extension use echo instead of returning a string.

This will allow concurrent Twig renderings using fibers.

[aszenz]

I would like to see a focus on component based templating over overriding/inheritance.

For that macros need an improvement specifically the need to import them separately in every block.

Would be great to support ux html component syntax natively for creating components.

A type checker plugin (pslam/phpstan) would be nice to have as well.

[TheCelavi]

Support for step debugging via source maps would be nice.

[JoshuaBehrens]

Plugin / Theme Structure like Shopware built around Twig. We had to built something as well and it feels bad to just copy if this could have been solved directly. And twig is already strong in multiple inheritance.

[JoshuaBehrens]

Static type support for generated php to increase performance and predictable execution. I already tried to approach it but optimisation levels were commented as too breaking. So we could break it here. #3928

[JoshuaBehrens]

Still be able to use Twig without pulling a lot of more dependencies.

E.g when you merge the twig symfony bridge into the twig package and in a small project just want to get some templating, you don't get the whole dependency clutter from the framework bundle. I don't use laravel/blade because you always get so much laravel stuff with it. I just want something small that can do inheritance and autoescape. Otherwise I would just use php right away.

I see benefits in merging some code from expression language as twig has to parse expressions as well and has "just" some nodes on top.

[75th]

Change the null-coalescing operator to an empty- (or falsy-) coalescing operator. All the time I have a variable that is empty but not null, and I want to do variable ?? 'Something', but I can’t. And if ? : works on falsiness, then so should ??.

EDIT: I expected some 👎🏻 reactions but I'd like to hear an explanation for them

[neluba]

Some type of script block to write multiple statements without typing {% %} for every line would be nice.

Something like this:

{% script %}
set counter = 0;
set color = "#33b5e5";
set list_items = [{  ... }, { ... }];

if (some_var is same as true)
    set list_items = [...list_items, { ... }];
endif
{% endscript %}

[ericmorand]

Definitely two things:

Removing entirely the line tag

It is not a template syntax but a compilation syntax, as discussed there: #353.

Rethinking the block philosophy

As of today, the block tag serves two purposes: declare a block and output a block. This not only creates confusion but also forces the compiler to make some arbitrary and non consistent decision like allowing a block definition inside a set but forbidding it inside a if (see #3926).

I think that the block tag should be dedicated to declare a block - and should be at the root level of template - and the block and parent functions dedicated to display them.

If you're intested in discussing this, I can write a special version of Twing that implement this specification so that we can test the behaviour with embed.

Typically a big breaking change.

[reinierbutot]

Change the null-coalescing operator to an empty- (or falsy-) coalescing operator. All the time I have a variable that is empty but not null, and I want to do variable ?? 'Something', but I can’t. And if ? : works on falsiness, then so should ??.

EDIT: I expected some 👎🏻 reactions but I'd like to hear an explanation for them

Its called the null coalescing operator for a reason. The whole php community is moving towards more strict typing, let's not create unexpected results by changing a well known concept like ??. For your case I would implement a custom function or just make sure the data sent to the template is correct.

[reinierbutot]

Add the possibility for global macro inheritance. Import in base template and available in all inheriting templates. Maybe a globalmacro keyword?

[75th]

Its called the null coalescing operator for a reason.

It's called that because that is what it does. If it did something else, it could be called something else.

The whole php community is moving towards more strict typing,

Twig is not PHP. It is written in PHP, it compiles to PHP, but it is its own language with its own goals. (inb4 "Your idea would be an ’own goal!’”) I don't believe its goal is merely "Enable back-end OOP PHP experts to write 1:1 PHP code in fewer characters".

let's not create unexpected results

This thread is specifically about breaking changes. Anything accepted from this thread will be equally unexpected to the person who compiles an old Twig file with the new version without reading the new docs.

For your case I would implement a custom function

?? is syntactic sugar for an easily conceived but lengthily typed combination of other Twig logic. The entire point is the brevity, and making it way more useful for common cases in a language that is not striving to be as strict as PHP proper is. And frankly, even if a null-coalescing operator is more appropriate for a stricter language, it kind of sucks that the question marks in ? : and ?? mean similar but very-importantly-different things.

or just make sure the data sent to the template is correct.

Shall we deprecate the set tag, then? What about the |map filter? The Twig language could be a lot smaller if we told all its users to just make sure the data is correct before it's sent to the template's context.

Anyway, I won't say any more, this is clearly a non-starter. I don't think it should be, though. I'm full-stackish, I can write clean and pretty and strictly typed OOP PHP myself, but I don't think those same sensibilities should be uniformly applied to a template language meant to make front-end developers' lives easier.

[ericmorand]

I agree with most of the points @75th is raising, but let me add a bit of fuel to them:

Twig is not PHP. It is written in PHP, it compiles to PHP, but it is its own language with its own goals.

This should be in the front page of every article and documentation dedicated to Twig. Twig is not "a templating language for PHP" for a good reason: the definition does not make sense. No language can be a language for another language. I'm sure that said this way, everybody would agree that it makes no sense.

Twig is a language, with compilers dedicated to be run by different runtimes (PHP, Ruby, NodeJS, browser runtimes...). And as such, it can - and must in my opinion - make its own decisions.

the question marks in ? : and ?? mean similar but very-importantly-different things.

This should definitely raise some concern: that the ternary operator is not strict but that the nullish coallescing one is is something that it not consistent and goes against @reinierbutot "The whole [...] community is moving towards more strict typing". If one is strict, the other must be strict. If one is not, the other must not be.

Shall we deprecate the set tag, then? What about the |map filter? The Twig language could be a lot smaller if we told all its users to just make sure the data is correct before it's sent to the template's context.

Absolutely correct: @reinierbutot, if your position is "just make sure the data sent to the template is correct", then why these last years have seen more and more functions and filters added to Twig that are dedicated to manipulate and generate data instead of just outputting data?

Why do the formatting filters exist? The backend knows everything required to send appropriately formatted dates or numbers or currencies or countries to the templates, so why were these formatting features added if "just make sure the data sent to the template is correct"?

Why do the date creation function exist? The backend knows how to create a date and should send dates to the templates, right?

I think we must not forget that a templating language main purpose is to process plain text. So, yeah, @reinierbutot, I agree with you that we must "make sure the data sent to the template is correct". But you have to admit that it is not the direction that Twig has been taking - and it is getting worse and worse everyday (eg the infamous cache tag that is the strict definition of something that is not in the scope of a templating language).

[srsbiz]

In template inheritance, variables set outside blocks in child templates should have priority over these declared in base template https://blog.srsbiz.pl/2021/07/scope-of-set-in-twig-templates/