Add Prettier for Handlebars to default blueprints

[jelhan]

I'm wondering if it is time to add Prettier for Handlebars to default blueprints.

This would be a follow-up to using Prettier for JavaScript files, which landed in #628. At the time we adopted Prettier for JavaScript files, Prettier for Handlebars wasn't stable yet. It is stable since Prettier v2.3, which was released in May this year.

@patocallaghan summarized the trade-offs very well in his proposal to use it for adopted-ember-addons: adopted-ember-addons/program-guidelines#20 (comment)

The following changes to default blueprints would be required:

1. Add ember-template-lint-plugin-prettier to devDependencies.
2. Change .template-lintrc.js to include the Prettier plugin:

   diff --git a/.template-lintrc.js b/.template-lintrc.js
   index f35f61c..0520e96 100644
   --- a/.template-lintrc.js
   +++ b/.template-lintrc.js
   @@ -1,5 +1,6 @@
   'use strict';
   
   module.exports = {
   -  extends: 'recommended',
   +  plugins: ['ember-template-lint-plugin-prettier'],
   +  extends: ['recommended', 'ember-template-lint-plugin-prettier:recommended'],
   };

3. Configure Prettier to use double quotes for Handlebar templates only (if using Ember < 4.10):

   diff --git a/.prettierrc.js b/.prettierrc.js
   index 534e6d35aa..e5f7b6d1ee 100644
   --- a/.prettierrc.js
   +++ b/.prettierrc.js
   @@ -1,5 +1,12 @@
    'use strict';
    
    module.exports = {
   -  singleQuote: true,
   +  overrides: [
   +    {
   +      files: '*.{js,ts}',
   +      options: {
   +        singleQuote: true,
   +      },
   +    },
   +  ],
    };

Open issues for Glimmer syntax, which may need to be fixed before:

• [handlebars] Named blocks can't be self closing prettier/prettier#11900 (fixed by v2.5.1)
• Correctly identify which backslashes are removed by glimmer prettier/prettier#12302 Prettier should not re-escape a backslash in a string literal prettier/prettier#11401 (fixed by v2.6.0)
• Wrap and indent long class names with glimmer parser prettier/prettier#10163
• Glimmer: tilde is moved next to the last word prettier/prettier#10847
• Handlebars: Print one element per line (like HTML printer) prettier/prettier#10178
• Use insertFinalNewline option from editorconfig for Handlebars / Ember files prettier/prettier#10759

[knownasilya]

Why num 2? I've been using it with single quotes app wide and it works great.

[jelhan]

Why num 2? I've been using it with single quotes app wide and it works great.

Our official documentation uses double quotes in Handlebar template files - even though it is using single quotes in JavaScript files. Also most of the applications and addons, I have seen, are following these convention. Changing this would cause unnecessary noise. Even if we want to alter the conventions anyways, I would prefer to not couple it with Prettier for Handlebars but have a separate RFC.

[NullVoxPopuli]

How is prettier for tailwind users? (Class attribute wrapping)
And how does it handle formatted nested helper invocations? (Not inlining)

Making those scenarios nice would bea blocker for me

[NullVoxPopuli]

Also, what's the config for folks who run everything through eslint?

[patocallaghan]

Thanks for opening @jelhan. Personally I wouldn't be against this. Having rolled it out over a large codebase the benefits of not having to think about template formatting is nice. Yes it's not perfect but neither is Prettier for JS and we've just accepted its choices there. Prettier for Handlebars is considered "stable" now and I think we should push for its adoption, if even to see what the blockers are or else we'll never see it get widespread usage.

@NullVoxPopuli re:your questions

How is prettier for tailwind users? (Class attribute wrapping)

So currently it will put all classes on a single line. We use Tailwind heavily and while the formatting here is not ideal we still decided to go with using Prettier for Handlebars as overall the positives outweighed the negatives. This is actually a contentious issue in the Prettier world in general. In the newly released Prettier 2.5 they've reverted some Tailwind specific changes for HTML formatting to just put all classes on one line until they can figure out something better.

And how does it handle formatted nested helper invocations?

I haven't seen any issues personally here but with regards these formatting tools we chose just to run with the choices Prettier made because once everything is up for debate you'll never align 😅.

Also, what's the config for folks who run everything through eslint?

We just followed @jelhan's awesome blog post which outlined how to configure ember-template-lint with prettier. Essentially it was just but this should also be part of the RFC:

yarn add -D prettier ember-template-lint-plugin-prettier

module.exports = {
  plugins: ['ember-template-lint-plugin-prettier'],
  extends: ['octane', 'ember-template-lint-plugin-prettier:recommended'],
 };

[NullVoxPopuli]

it will put all classes on a single line.

Well, before I adopt prettier in templates, i'd want the printWidth respected.
For tailwind users, this is currently an unacceptable compromise, imo.

I haven't seen any issues personally here but with regards these formatting tools we chose just to run with the choices Prettier

I understand this is the prettier philosophy, but we still have a lot of say in how things are represented, since prettier support is still early.
For example, if i have 4 nested helper invocations, that better not be inlined to a single line. I know not of a single person who would think that's on improvement.

[NullVoxPopuli]

Example of obviously worse behavior:
https://prettier.io/playground/#N4Igxg9gdgLgprEAuEAeAJgSwG4AIwA2AhgM4kC8A5ADpS64BGA5gLQMECucjEATunF4sATD36CWvOOlzwAHjBZMpCWvQBm0RQwgEZABzksArLn0BPEbmWYZTIvpYAWXCQAWRdBADua1x69vJV4ic1kQqBJMGExoFiICAlxNMA4SInY4P15MKFYXekLCvz9gYEx1XAABLHTMmT96Slz4ELAY7DgWWoyCaUpcRtxm2EEidpw4GjpcAF9ZoaKi0vLKgAo+XDW4AEdqqIAvbkoCJkoASi3d6uwiHKJYYeJeJinz86HKTVgWU+StNi6dDTIpfAEAWxk30U4OkmA44JBcwWUEoAD4VlsYG5MCQAHSaCC4ACMuGEl3mJRmZQAxH0YFsSHwGYslmt1JgCK1BjMlkU1l4WNjckwSDy+XzSWtIOD9Bx4MM3II3rgAMyXVmgiDoYGa+jvcW4Ui4AA+BFxMBNlN5uFpcHGblw5pIDONJqgCKtKIlZQ94OtRTKAHp7WA3AHbcAg-Tragg1hsBibbQyuZMHA9LhonBwUQs-BwQwth53EbyOyIETSeTLjAIFRzHdKPMQAAaEAQfQxaAkZCgO68HwABTuCF7KAS3lCvfbDDaAGs4DAAMpEWEAGVycGQ6gSJDgs4XS+X+nGIuQMF4XHbOYY0gE6HXDyYHCIrwAYnxczAYnlkCAiHlCA2xANwYHBAgAHUcXgEhTzAOBlzHaIcGicx-zAMgQNyfdeBgIcQiYXMdz3A8QAAKxIORlxFPoAEUOAgeASIIfd21PXhcP-JhzXBWFeBA-QclgSDbGxZAAA4AAZ2MHfdIJCfR-yEuBcM6ECdkY+ACM7ccAJIFgoDgaRpBAqRNMwKQCLfYikF3ViyP3cFMAvK9HNouAGKY7c7NI9sYAyUT0HEpBhH8kJORFABhCA+KIf9VOMEC0jgAAVDJx3stiQGwLgAEkoAEWBlzAHIuwAQUK5cYHMPoWP3eYgA

[NullVoxPopuli]

And with printWidth=40

https://prettier.io/playground/#N4Igxg9gdgLgprEAuEAeAJgSwG4AIwA2AhgM4kC8A5ADpS64BGA5gLQMECucjEATunF4sATD36CWvOOlzwAHjBZMpCWvQBm0RQwgEZABzksArLn0BPEbmWYZTIvpYAWXCQAWRdBADua1x69vJV4ic1kQqBJMGExoFiICAlxNMA4SInY4P15MKFYXekLCvz9gYEx1XAABLHTMmT96Slz4ELAY7DgWWoyCaUpcRtxm2EEidpw4Gig-AF9ZoaKi0vLKgAo+XDW4AEdqqIAvbkoCJkoASi3d6uwiHKJYYeJeJinz86HKTVgWU+StNi6dDTIpfAEAWxk30U4OkmA44OmjXmtEoAD4VlsYG5MCQAHSaCC4ACMuGElxRdEGVLKAGI+jAtiQ+IzFks1upMARWtSlny1l4WNjckwSLy+UtSWz+ZBwfoOPBhm5BG9xRL6ABmaWFS7apoQdDA2i0D5U+iXUi4AA+BFxMCtlKKdLg4zcuFtJEZlqtUARDoWZqdwF94MdhTKAHoXWA3GHIwzKagI1hsBjA0MyuZMHA9LhonBwUQ8-BwQwth53LgiOQORAiaTyZcYBAqOY7pR5iAADQgCD6GLQEjIUB3Xg+AAKdwQQ5QCW8oSHPYYbQA1nAYABlIiwgAyuTgyHUCRIcCXq-XG-04xFyBgvC4PYLDGkAnQO4eTA4RFeADE+IWYBiPJkBAIgFQgbsQDcGBwQIAB1HF4BIK8wDgDdp2iHBonMECwDISDchPXgYHHEImELQ9j1PEAACsSDkDcRT6ABFDgIHgSiCBPHsr14IiQKYW1wVhXhIP0HJYDg2xsWQJwAAYeLHE84JCfQQPEuAiM6SCdjY+BSL7GdQJIFgoDgaRpEgqRdMwKRSO-CikCPLjqJPcFMFve9XKYuBWPYg8nKonsYAyKT0BkpBhGCkIuRFABhCBhKIEDNOMSC0jgAAVDIZ2c7iQGwLgAEkoAEWANzAHJ+wAQVKjcYHMPpOJPeYgA

[NullVoxPopuli]

Tldr, requirement for me is:

• Class wrapping
• formatting nested helper invocations based on readability, rather than printWidth

[patocallaghan]

@NullVoxPopuli Thanks for these, they give more concrete examples of what you'd like improved. Should we open issues against Prettier to generate discussion if they haven't already? Personally I'm fine with the behaviour of nested helpers obeying printWidth (maybe I'm nuts 😅) but I do agree the class on a single line at least respecting printWidth would be an improvement.

[scottmessinger]

While Prettier could be improved in some specific ways (like those mentioned above), I think having it in the default blueprint is an enormous benefit and I think we should do it. I'll never go back to having to manually format HBS files and I would love for each new user to Ember to experience the simplicity of automatic formatting by default.

[ro0gr]

At the end formatting is needed to improve experience for the source code reader, since we read more than write. So if it'd impove DX but degrade readability(for instance due to some basic issues mentioned by @NullVoxPopuli), I'd say it may be a bad default.

[kiwiupover]

We found two issues this the prettier printer when we ran it on our app.

1. prettier added an extra \ to backslash in a component argument value.

{{!-- input --}}
<Component @date="dateFormat:YYYY-MM-DD hh\:mm\:ss" />

{{!-- output --}}
<Component @date="dateFormat:YYYY-MM-DD hh\\:mm\:ss" />

2. Prettier didn't understand this older mustache syntax

{{!-- input --}}
{{#let importInput.[0] importInput.[1] importInput.[2] as |importRow|}}
  {{importRow.name}}
{{/let}}

{{!-- output --}}
{{#let importInput.0 importInput.1 importInput.2 as |importRow|}}
  {{importRow.name}}
{{/let}}

https://prettier.io/playground/#N4Igxg9gdgLgprEAuEAeAJgSwG4D4A6UABEagMIQC2ADtAjEQALoCG8AvPiK-AGIQAnSmyQBNcaIC0AWWmSAIvKIALZfnxJKldUgDOurkQD0BYkUIlgwAMQAbOA0w1BMAJJRqAVxgA6ANoADAC6RE60Am4e3v4AjCFhLu5evn4ATCEsukQAPgkRAEoQAO7ZAL6lFuYwVnkwhUU+UCyUcOWVVkb2MG1QqEZYeJUkIAA0IBDUMJjQusigLAICxQAKCwizKCy2RSwAnrNjAEYCLGAA1g4Ays1wADKYUHDIAGZbunBHJ+dX1KcPAObIGACTwfEBwSiHODodDQ24sKD-Twsf5wfhCNhTRHIEAsbwQUYgZQwSi2ADqykw8F0vzAcEu6ypOCpuxxYH0hIe7wiyxO-2ELzeYIAVroAB6XAH2ACKngg8EFtneY1+Am5OP+ticLQEhOoAgeMDJmHQMGUyAAHAEVUt3mSTtQcfq4NzsE8xgBHOXwXkTDa43SSR7Q6GEgRwL2YcO8lECpCvJVg96UTBAkFJqVwWXyp7xoVjGAsQ7G03mpCpAsnTBaxEULQsHEugCshM87wAKkWNgnlSBsKD3LDYJcwAbJgBBKDoS4wXb2RXvcpAA

[scottmessinger]

At the end formatting is needed to improve experience for the source code reader, since we read more than write. So if it'd impove DX but degrade readability(for instance due to some basic issues mentioned by @NullVoxPopuli), I'd say it may be a bad default.

This feels rather reductive to me. For us, prettier has improved the readability, despite a few area where it could be better. Suggesting the lack of perfection causes a net decrease in readability isn't consistent with our experience with prettier.

If there are issues where prettier is changing the semantics of the templates (as @kiwiupover points out), that's definitely a reason to think twice about making prettier a default. We haven't run into many of those and they've all been solved by adding a prettier-ignore comment.

[NullVoxPopuli]

you shouldn't have to disable lint/formatting when it's the default.
that's a bug, ya know?

I'm good with prettier for templates being added by default.. but only when it's ready.
It seems there are still bugs to fix atm :-\