Feature request: Twig support

[Kocal]

(Related to #4056 I suppose.)

On some large codebase, when many (old and new) developpers write/modify code, it's really borring and to review linting issues on Twig templates. 😞
I know there is also linting tools like asm89/twig-lint and the command php bin/console lint:twig inside a Symfony project, but they only check if the syntax is valid. 😕

It would be nice if Prettier can handle Twig files (.twig), but also HTML Twig files (.html.twig), in order to have clean Twig files everywhere. 🎉

The following elements that should be prettified:

• {% %} and {{ }} tags
• Filters
• Array and Hashes

Given the following snippet (taken from admin/blog/edit.html.twig from Symfony Demo, but uglified on purpose):

{#
    By default, forms enable client-side validation. This means that you can't
    test the server-side validation errors from the browser. To temporarily
    disable this validation, add the 'novalidate' attribute:

    {{ form_start(form, {attr: {novalidate: 'novalidate'}}) }}
#}

{%  if show_confirmation| default(false) %}
    {% set attr = {'data-confirmation'  : 'true'} %}
    {{  include('blog/_delete_post_confirmation.html.twig')   }}
{% endif %}

{{ form_start(form, {  'attr': attr|default({})}) }}
    {{ form_widget(form) }}

    <button 
        type="submit"
        class="{{ button_css|default("btn btn-primary") }}"
    >
        <i class="fa fa-save" aria-hidden="true"></i> {{ button_label|default('label.create_post'|trans) }}
    </button>

    {% 
        if include_back_to_home_link|default(false) 
    %}
        <a href="{{ path('admin_post_index') }}" class="btn btn-link">
            <i class="fa fa-list-alt" aria-hidden="true"></i> {{ 'action.back_to_list'|trans
 }}
        </a>
    {% endif %}
{{ form_end(form) }}

The prettified should be something like this (this is my code style, but if Prettier on Twig files will be a thing, maybe we should ask to twigphp/Twig or the Twig community what they prefer):

{#
    By default, forms enable client-side validation. This means that you can't
    test the server-side validation errors from the browser. To temporarily
    disable this validation, add the 'novalidate' attribute:

    {{ form_start(form, {attr: {novalidate: 'novalidate'}}) }}
#}

{% if show_confirmation|default(false) %}
    {% set attr = { 'data-confirmation': 'true' } %}
    {{ include('blog/_delete_post_confirmation.html.twig') }}
{% endif %}

{{ form_start(form, { attr: attr|default({}) }) }}
    {{ form_widget(form) }}

    <button type="submit" class="{{ button_css|default("btn btn-primary") }}">
        <i class="fa fa-save" aria-hidden="true"></i> {{ button_label|default('label.create_post'|trans) }}
    </button>

    {% if include_back_to_home_link|default(false) %}
        <a href="{{ path('admin_post_index') }}" class="btn btn-link">
            <i class="fa fa-list-alt" aria-hidden="true"></i> {{ 'action.back_to_list'|trans }}
        </a>
    {% endif %}
{{ form_end(form) }}

Thanks for your consideration, I'm sure that will be helpful to many people 🙂

[alexander-akait]

I think it is out of scope of prettier (core). We support plugin system https://prettier.io/docs/en/plugins.html and real plugins with code how plugins should be implemented. I think the right decision would be to implement the plugin.

[Kocal]

Ah yeah, I totally forgot about plugins.

Well, maybe it's the good time for me to write my first own plugin 👀

[alexander-akait]

Thanks for issue, i closing the issue here because twig is not widely language for web, it is template engine for PHP, maybe we can this about this in https://github.com/prettier/plugin-php, feel free to open issue, i think it is good idea

[allejo]

@evilebottnawi while Twig is used solely in the PHP world, the syntax itself is based on other languages which, in total, are widely used across the web.

• Jinja (Python)
• Django (Python)
• Nunjucks (JavaScript)
• Liquid (Ruby)
• Fluid (C#)

[alexander-akait]

@allejo so as i describe about better put this into php plugin, feel free to open issue, i can help with this

[chrisblossom]

Just FYI, I've used Twig in the past with javascript via nunjucks (as @allejo mentioned).

[allejo]

I don't feel that the PHP plugin would be the best place for this support since the syntax is used in so many other languages as well. If anything, maybe its own plugin? But I'd argue the closest relation of this would be a superset of HTML.

[Anahkiasen]

I don't think it belongs in the PHP plugin either, definitely its own plugin and it's definitely more HTML with some bells than it is related to PHP. In fact the very design of the language is to prevent you from using any PHP in your views :p

[alexander-akait]

Reopen and mark as discussion

[janbiasi]

Twig is also used as a templating language for a lot of Frontend projects which will have a Drupal Backend (which takes our components to render). This is also a pretty common case imo. but I think that the twig language syntax doesn't belong to the php, neither to the core/html part. The best would be to create an independent plugin for the language.

[alexander-akait]

I think it should be implemented as plugin, because it is not popular language for templates

[allejo]

May I recommend this issue be renamed to something along the lines of "Jinja/Twig/Django/Liquid-like support" to avoid any further confusion? As mentioned, Twig by itself might not be hugely popular relative to the whole internet, but the syntax/markup itself is used by a lot of major CMSes/products around the world:

• Python (Django)
• PHP (Symfony/Drupal/October/phpBB)
• Ruby (GitHub Pages/Shopify)
• C# (Orchard CMS)

I agree that support for this would make sense as a plug-in. However, I strongly disagree that this syntax isn't popular.

[Kocal]

Twig can also be used in Wordpress with Timber plugin.

[alexander-akait]

We have good plugin api, any developer can start implement this

[tpinne]

It can also be used in any (standalone) Frontend-Stack with:
https://github.com/twigjs/twig.js/
https://github.com/ericmorand/twing

[alexander-akait]

#5944 (comment)

[alexander-akait]

We don't have enough developers support new language, better implement plugin

[Anahkiasen]

I tried my hand at this some time back but while Twig itself doesn't have very complicated syntax I couldn't find how to make a plugin for a language that is a superset of another (here, HTML) personally. I'm not saying it's not possible I'm sure it is, but could be why we haven't seen a plugin pop up yet despite Twig's syntax being relatively basic

[Kocal]

Someone on Twitter linked me a link to Prettier plugin for Twig files: https://github.com/trivago/prettier-plugin-twig-melody

[thibaudcolas]

I’ve been looking into this as well for Django Templates. As @allejo mentions there are a lot of templating languages that use nearly identical syntax, so it feels valuable to group the discussions about them, or even have a shared plugin implementation. Here are the template languages in question:

• Twig, Feature request: Twig support #5944
• Django Templates, HTML -> No Django template tags support {% tag %} #5581
• Jinja / Nunjucks, Jinja Template Support #5754
• Liquid, which Prettier already has some support for in Markdown files
• Handlebars (already supported) & Mustache also are somewhat similar.
• (also worth a mention – general guidance on parsing & pretty-printing HTML templates: Support for .html.eex files? #5286 (comment))

For all of the above here are the WIP plugins that have been built so far, all using different approaches:

• Nunjucks, https://github.com/justrhysism/prettier-plugin-nunjucks (using Nunjucks parser)
• Django Templates, https://github.com/robertquitt/prettier-plugin-djangohtml (using https://github.com/fb55/htmlparser2)
• Twig / Melody? https://github.com/trivago/prettier-plugin-twig-melody (using Melody parser)

I think it’s also worth mentioning other related plugins:

• https://github.com/UnwrittenFun/prettier-plugin-svelte (using Svelte parser)
• https://github.com/prettier/plugin-pug (using PUG’s lexer)

---

I didn’t spend much time assessing the plugins just yet but to me it feels like support for any or all of the above could be approached in a few different ways:

• Extend current Handlebars support to handle {% %}. Prettier uses Glimmer directly so this is likely impossible, but worth checking.
• Replace template syntax with placeholders -> run through HTML or Handlebars -> re-add template syntax (Jinja Template Support #5754 (comment))
• Use Nunjucks parser & AST if suitable (https://github.com/mozilla/nunjucks)
• Use Twig JS port parser / AST if suitable (https://github.com/twigjs/twig.js/)
• Use Liquid JS port parser & AST if suitable (https://github.com/harttle/liquidjs)
• Custom parser e.g. with https://github.com/SAP/chevrotain

I’ve looked into differences between Django Templates and Jinja/Nunjucks before, and to me it feels like it’s 100% possible and desirable to have a single plugin that supports these three, and Nunjucks has the advantage of having an official JS parser. I didn’t look into Twig / Liquid much more to determine how close they are to Nunjucks, but it doesn’t feel like that big of a stretch to support them as well.

If there was a single plugin supporting all of Django Templates, Twig, Jinja2, Nunjucks, Liquid, ideally backed by a battle-tested parser (rather than one developed just for the plugin), then it feels like there would be a better case for having this support built-in.

---

I’m not sure how much time if any I can dedicate to this but to me it feels like a good next step should be to assess the existing plugins and see if (with the different approach each took) they would be likely to be compatible with other syntaxes. I presume individual plugin authors might find it easier to only focus on one of the template languages, but long-term it would be better to have a plugin support multiple syntaxes – if at all possible.

[truls1502]

+1 for Twig support, 👍especially when I am using twig and Atomic Design Systems (PatternLab) for the frontend!

At the moment I am using friendsoftwig/twigcs via composer.

[sghoweri]

+1 for Twig support, 👍especially when I am using twig and Atomic Design Systems (PatternLab) for the frontend!

At the moment I am using friendsoftwig/twigcs via composer.

Same!!

[truls1502]

I am just wondering what is the status of this thread, or how should we discuss this issue? 😊Or, are we waiting for a patch to test?

[justrhysism]

@thibaudcolas Just an FYI, the approach I was taking using the Nunjucks parser was been tossed in the bin, and I've rewritten it to use mustache—which has significantly simplified the printer.

It was a few months ago so my memory is hazy, but using the Nunjucks parser didn't provide enough information on the syntax itself. The most pertinent example I came across was there was no way to tell the difference between {{ foo.bar }} and {{ foo['bar'] }} from the AST returned from the parser.

There were also issues with custom tags and being able to determine how they should be treated (there is still this issue to a degree, I've had to set up options to extend the "known" tags).

The mustache approach could probably be genericised and adapted to the above-mentioned languages. (At my end progress has slowed because I just had another baby and they are time-sucks haha)

[0x7061]

@truls1502 @sghoweri Just clarifying: twigcs doesn't fix/format right? It just lints and reports style issues?
Have you been able to combine twigcs with formatting in any way by now?

[thorn0]

Prettier isn't going to add more languages to the core. This should be implemented as a plugin.