Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We鈥檒l occasionally send you account related emails.

Already on GitHub? Sign in to your account

Feature request: Twig support #5944

Closed
Kocal opened this issue Mar 6, 2019 · 26 comments
Closed

Feature request: Twig support #5944

Kocal opened this issue Mar 6, 2019 · 26 comments
Labels
locked-due-to-inactivity Please open a new issue and fill out the template instead of commenting. scope:plugin The requested enhancement doesn't belong in Prettier core, but would be a good fit for a plugin status:needs discussion Issues needing discussion and a decision to be made before action can be taken

Comments

@Kocal
Copy link
Contributor

Kocal commented Mar 6, 2019

(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:

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
Copy link
Member

alexander-akait commented Mar 6, 2019

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
Copy link
Contributor Author

Kocal commented Mar 6, 2019

Ah yeah, I totally forgot about plugins.

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

@alexander-akait
Copy link
Member

alexander-akait commented Aug 7, 2019

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
Copy link

allejo commented Aug 7, 2019

@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.

@alexander-akait
Copy link
Member

alexander-akait commented Aug 7, 2019

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

@chrisblossom
Copy link
Contributor

chrisblossom commented Aug 7, 2019

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

@allejo
Copy link

allejo commented Aug 8, 2019

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
Copy link

Anahkiasen commented Aug 8, 2019

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 alexander-akait added the status:needs discussion Issues needing discussion and a decision to be made before action can be taken label Aug 8, 2019
@alexander-akait
Copy link
Member

alexander-akait commented Aug 8, 2019

Reopen and mark as discussion

@janbiasi
Copy link

janbiasi commented Sep 3, 2019

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
Copy link
Member

alexander-akait commented Sep 3, 2019

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

@allejo
Copy link

allejo commented Sep 4, 2019

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
Copy link
Contributor Author

Kocal commented Sep 4, 2019

Twig can also be used in Wordpress with Timber plugin.

@alexander-akait
Copy link
Member

alexander-akait commented Sep 4, 2019

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

@tpinne
Copy link

tpinne commented Sep 11, 2019

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

@alexander-akait
Copy link
Member

alexander-akait commented Sep 11, 2019

#5944 (comment)

@alexander-akait
Copy link
Member

alexander-akait commented Sep 11, 2019

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

@Anahkiasen
Copy link

Anahkiasen commented Sep 11, 2019

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
Copy link
Contributor Author

Kocal commented Oct 18, 2019

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

@thibaudcolas
Copy link

thibaudcolas commented Nov 5, 2019

I鈥檝e 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:

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

I think it鈥檚 also worth mentioning other related plugins:


I didn鈥檛 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:

I鈥檝e looked into differences between Django Templates and Jinja/Nunjucks before, and to me it feels like it鈥檚 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鈥檛 look into Twig / Liquid much more to determine how close they are to Nunjucks, but it doesn鈥檛 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鈥檓 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
Copy link

truls1502 commented Dec 8, 2019

+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
Copy link

sghoweri commented Dec 13, 2019

+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
Copy link

truls1502 commented Feb 4, 2020

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
Copy link

justrhysism commented Feb 5, 2020

@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鈥攚hich 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)

@codepushr
Copy link

codepushr commented Mar 22, 2020

@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 thorn0 added the scope:plugin The requested enhancement doesn't belong in Prettier core, but would be a good fit for a plugin label May 7, 2020
@thorn0
Copy link
Member

thorn0 commented Jun 22, 2020

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

@thorn0 thorn0 closed this as completed Jun 22, 2020
@github-actions github-actions bot added the locked-due-to-inactivity Please open a new issue and fill out the template instead of commenting. label Sep 21, 2020
@github-actions github-actions bot locked as resolved and limited conversation to collaborators Sep 21, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
locked-due-to-inactivity Please open a new issue and fill out the template instead of commenting. scope:plugin The requested enhancement doesn't belong in Prettier core, but would be a good fit for a plugin status:needs discussion Issues needing discussion and a decision to be made before action can be taken
Projects
None yet
Development

No branches or pull requests