Just comment this line out and update snapshots for now. When we release it we'll uncomment.

Newline here (there's a handful more, could you run through all of them?)

We'll want to preserve the empty line above.

It seems overkill to always break

Does it respect the jsx-bracket-same-line option?

No it doesn't. I think a ternary in a few places would fix that though. I didn't write any support for options! :(

It would be great to support it :)

Adding a new language to prettier works in two phases. The first one is to print everything in a correct way, which you mostly did here. The second one is to make all the things than can be thrown at it look good.

You’re now entering the second phase :) So expect to do a lot of tweaks everywhere.

I expected this! I'm really happy to do this part too. I figured that it would need tweaking because a lot of the decisions I made were based off asking a few people in the community and then picking from what is available. I will be in airplane for a few hours next week so I'll have plenty of time to implement whatever is decided upon.

You're not wrapping here?

This is one the tricky ones to decide. You wouldn't break this string up to multiple lines:

const hello = 'A string that is over 80 chars long';

I could take text and break on space, but I think that's against what I would expect from prettier.

I would recommend looking at what prettier outputs for jsx and try to be as close as possible. This has been battle tested over time and it hasn’t been a big source of issues.

I don't understand the heuristics you chose. Sometimes it is in one line, sometimes it breaks, for things that look similar.

I would prefer that HTML tags would break as frequently as block elements, but I remember running into some situations where that would cause some very ugly formatting.

Perhaps block elements should also always break? What would be best?

Here's a small example for JSX: Playground link

Input:

<div>
  {a}
</div>;
<div>{a}</div>;
<div a>{a}</div>;
<div a b>{a}</div>;
<div>{a}{b}</div>;

Output:

<div>{a}</div>;
<div>{a}</div>;
<div a>{a}</div>;
<div a b>
  {a}
</div>;
<div>
  {a}
  {b}
</div>;

It always break if there's >2 attributes or >2 values and inlines otherwise.

This is a small example but you should look at the JSX source code and see all the heuristics it does to make it look good.

I would name all those "handlebars". Except for JavaScript, we started naming the parser after the language it parses and not the actual name of the parser. This is easier for people to figure out which to use. It would be nice to rename it to --language at some point but we'll see.

I agree that renaming from glimmer to handlebars would make sense. It's just that at this moment, glimmer doesn't support partial statements, which handlebars does support. So it's kind of a specific caveat that they're different.

Do you know if there's a list of the differences between the two?

I'm not sure, I'll ask the maintainers of the project. @mmun

Handlebars is a plain text templating language. In practice it is often used as an HTML templating language, but it is also commonly used for templating configuration files (toml, ini, yaml, etc).

Glimmer is only used for templating HTML/DOM. There are a couple differences from vanilla HTML:

• The parser will hard error if non-void tags aren't balanced. It also only attempts to handle "content" HTML, e.g. it doesn't correctly handle <script> parsing. I don't think we plan to change that any time soon.
• There are a few extensions we've added to HTML that let us differentiate HTML attributes from component arguments:

<MyComponent class="red" @data={{myData}}>

You can also pass blocks as arguments (I believe they are commonly called render props in React)

<MyComponent>
  <@header=>This is a header!</@header>
  <@header=>This is a footer!</@header>
</MyComponent>

@mmun isn't it technically "HTMLBars" instead of "Glimmer" with "Glimmer" just implementing a parser for "HTMLBars"?

@Turbo87 It's true that that is how we launched it but it was always for lack of a better name. You won't find references to HTMLBars in the guides/API docs anymore. The Glimmer brand now encompasses a DOM templating language, a runtime VM, and an experimental application framework (http://glimmerjs.com)

@vjeux Let me start by saying thank you very much for working on prettier and for reviewing this PR! And thanks to @robert-j-webb for working on it!

I completely agree with you that we should minimize confusion with the configuration. Taking a step back away from Glimmer for a second, what configuration would you propose to differentiate between .txt.hbs, .md.hbs, .html.hbs, .toml.hbs, etc? Each variant would need different formatting for the non-Handlebars parts. It's also plausible to me that the stuff inside the curlies ({{ ... }}) might be slightly formatted differently depending on the variant as well.

I think that answering this question may shed some light on how to deal with Glimmer.

I’m not super familiar with handlebars but the philosophy we followed with prettier so far is to take use cases one by one and make them really good. So my recommendation would be to make it work perfectly for Ember and then we can figure out how to handle more use cases. My guy feeling is that there’s a big market for people eager to get prettier to work for the html variant and low interest in the other variants right now.

The html parser/output seems to be completely broken :p

Yeah it's not great. I could fix (it's very similar to handlebars) it but I wanted to scope my PR around just getting handlebars working because it's already so much code.

Yeah, don’t worry about the html printer