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.

[stof]

@alinceDev the hard part about that is that Twig is not specific about HTML (if you render something else, using HTML comments will just break everything). And even in HTML, comments are not allowed in all contexts. So this is unlikely to go in the core. But if you want to do that in your own project, it might be doable with a node visitor.

[GromNaN]

This could done in a third party package by wrapping the loader and prepend the template when the template contains an HTML tag.

[mikespub]

As someone who often switches from PHP to Python and back, I'd like to keep the Twig vs Jinja differences small for any future evolution, both in concept, syntax and implementation.

I'm not sure what top 3 changes that might require, but I'm sure you can think of some based on current/future feature set of both...

And since I sometimes have to deal with the same templates in Javascript as well, please keep twig.js up to date too :-)

[mx03]

date filter that return null if value is null instead current date, as its much more error prone than null.

If the value passed to the date filter is null, it will return the current date by default. https://twig.symfony.com/doc/3.x/filters/date.html

At the moment its possible to achieve this with a ternary operator {{ post.published_at is empty ? "-" : post.published_at|date("m/d/Y") }}

but its much more logically if you just can chain the default filter {{ post.published_at|date("m/d/Y")|default('-') }}

[PabloKowalczyk]

switch/match (or both) , please :)

[pontus-mp]

I think this has already been mentioned earlier, but I'll still add my 2 cents. Something I miss is embed-style capabilities in a more local scope. I'd imagine doing this neatly would affect BC.

Something like this but more thought through:

{% embeddable Marquee %}
  {# Same content as in a normal .twig file for embedding, so it's easy to move into a separate file if needed later #}
  <marquee>
    {% block content %}
      Default content
    {% endblock %}
  </marquee>
{% endembeddable %}

{# Using same embed block as a classic embed, but with a named embed  #}
{% embed _self.Marquee %}
  {% block content %}
    <blink>A blink inside a marquee!</blink>
  {% endblock %}
{% endembed %}

{# Maybe even add macro-like import functionality, which would make them more or less replace macros #}
{% import 'my_embeds.twig' as Embeds %}
{% embed Embeds.Blink %}
  {% block content %}
    Blinky!
  {% endblock %}
{% endembed %}

[75th]

Functions written in Twig that work like macros, but return a value instead of printing something.

{% function restructure_data(data) %}
  {% set output = { title: data.post_title } %}
  {% if data.body is not empty %}
    {% set output = output|merge({description: data.body}) %}
  {% endif %}

  {% return output %}
{% endfunction %}

[cuchac]

Add support for HTML "attribute" expressions. For example

<ul twig:if="users">
    <li twig:for="user in users">
        {{ user.name }}
    </li>
</ul>

Or at least add support in Parser/Lexer/Tokenizer to write Extension supporting this syntax - able to parse HTML and add more syntactic sugar.

[ericmorand]

@cuchac Twig is not an HTML superset, it is a templating language. How would Twig be able to detect "HTML"?

Would the following template be valid, and if not, how is Twig supposed to detect that the use of twig:for="user in users" is not valid here but valid in your example?

.foo twig:for="user in users" {
    {{ user.name }}
}

[cuchac]

@ericmorand Hello, there are many examples of PHP template languages that supports such syntax. Many frontend developers prefer such "attribute" control statements. For example https://phptal.org/, https://latte.nette.org/, https://github.com/goetas/twital, ...

Twig already knows about file type - it applies different escaping to variables in HTML and JS. I will happily write extension that supports such syntax, but as far as I know, there is no support for parsing context outside twig tags.

Look what Twig UX Components had to do - https://github.com/symfony/ux/blob/2.x/src/TwigComponent/src/Twig/TwigPreLexer.php - they had to write complex custom parser to hack components syntax like <twig:Button ...> and they regularly fix parsing errors - https://github.com/symfony/ux/commits/2.x/src/TwigComponent/src/Twig/TwigPreLexer.php

Every extension that wants to use such HTML-dependent syntax would have to create custom parser, introduce many bugs and probably break other extensions.

If internal tokenizer/lexer/parser will have support for HTML syntax, or some external extension will provide it with support from core, many valuable extensions can be created. For example let's close frequent XSS errors by activating JS escaping whenever <script> tag is hit inside HTML and it is very easy to forget to add proper {% autoescape 'js' %} tag.

[ericmorand]

If internal tokenizer/lexer/parser will have support for HTML syntax

That's my point: it would make Twig an HTML parser, opinionated in favor of just one syntax among the infinite possible things that Twig is able to output. Arguably, why not propose syntactic sugar for CSS - and thus make Twig a CSS parser too?

For example let's close frequent XSS errors by activating JS escaping whenever Githubissues.

Githubissues is a development platform for aggregating issues.