The very basics... auto-formatting in .eex

I’ve seen a few related threads asking about auto-formatting .eex files, so I apologise in advance for any redundancy… although all seem to have either no responses, or no firm resolution.

I’ve started a new Phoenix project, and I’m importing large chunks of React component code that I want to convert to basic HTML and EEx tags.

In React, I’d just use Prettier or ESLint - and would never think twice about formatting. Save a file, et voila - everything’s auto-indented, all the tag attrs are in the right place, and everything just looks right. I can copy and paste code and not worry about it not aligning.

I feel like I’m falling at the first hurdle with .eex - I haven’t found a single IDE or plugin that handles it. I tried Prettier, and it broke my <%= tags %>. I tried both IntelliJ and WebStorm (which I guess uses the same plugin); neither Reformat Code nor Auto-Indent Lines had any effect. I tried two plugins in VSCode… neither seemed to affect formatting, either.

What does everyone else use to keep their EEx in check?


Closest thing I’ve found is telling vscode .eex is .html. But you lose the .eex syntax highlighting. I’m interested in hearing what others have discovered. I don’t spend a ton of time in .eex files so it hasn’t been too big of a deal for me.


That’s the closest I’ve got, too. Which plugin do you use?

Here’s the results/issues I’ve seen so far:


Won’t parse EEx that contains strings due to the extra double quotes, and so fails to format entirely:


This did format, but had the same double-quote issue with EEx tags that added a \n before the closing quote. Also added a random newline between the closing </script> (although perhaps that’s standard Beautify behaviour? :man_shrugging:

I have a feeling I cannot possibly have exhausted all the options. Are there any other options I’m overlooking?

Thanks in advance!

1 Like

I posted an update about the configuration fo beautify to format EEx template as good as possible now. Works quite well now for me.
Have a look at


I’m curious why VSCode has such issues formatting eex files? In a *.html.eex file uses the normal HTML formatter for the file and the Elixir formatter for inside <%...%> parts, it can arbitrarily nest formatters based on various markers (For *.html.eex files the start marker is <% and the end marker is %>, like XML in Scala and PHP in HTML and so forth. Can’t the same thing be done in VSCode as done in Formatting works as expected, syntax coloring works as expected, intellisense works as expected, etc…


That’s really nice, I didn’t know that Atom could do that.

AFAICT, only one ‘beautifier’ can be activated per file type in VSCode. I could be wrong, but I haven’t seen any settings to the contrary.

1 Like

That sounds like a really bad misdesign if so… Even the ancient vim and emacs have primary buffer types and sub buffer types (that modeled after from what I’d guess). A single file type may not have just a single ‘language’ in it, so that seems really bad design… o.O

I tried using VSCode for a bit, and although I like that the elixir plugin shows specs in it (and I’m wondering why it doesn’t show it in even though its the same author when absolutely can do the same thing), it was lacking so many plugins that just make my life so much easier that are just common in and EMacs both (I use both quite routinely, depending on if I’m in a GUI or console system). It’s ecosystem just seems really young and incomplete in comparison. used to be a huge amount slower than VSCode but that’s been fixed for well over a year now as well to any factor that I could tell the difference between (they went through a big performance push for like a year there).

I’d really say give a try, though I really hope that @specs display from the elixir-ls plugin gets added someday. ^.^


Did you ever compare Atom and Sublime Text 3 by the way?

Thank you! I’ve switched from Prettier to Beautify in VSCode using your settings and finally I have proper formatting inside .eex files.

1 Like

You’re welcome. Glad to hear that I could help.
If you notice anything wrong, please let me know.

I’ve barely ever looked into sublime text actually… ^.^;

I’m a bit particular about certain features that I really have to have to ‘feel’ productive. Proper intellisense is a big one (I’m still unhappy here with this for Elixir with elixir-ls, but that’s mostly because of Elixir the language, statically typed languages are far far superior here). Context sensitive syntax coloring (like the syntax coloring of these forums or VSCode on Elixir are just bad, like horribly bad, even Atom and emacs emulate this well enough to be indistinguishable from proper context sensitive syntax coloring in a ‘real’ IDE like KDevelop). Fast responsiveness (elixir-ls’s plugins in both atom and vscode is super slow here compared to what I’m used to for other languages and it bugs me to no end). Among a few other minor ones (git interactions and blame displaying, etc… etc… but atom, vscode, emacs, etc… all do this very well, etc…).

Oh, and it really must support embedded types within other files, like how both emacs and atom can do but vscode can’t, where you can get html in one context, eex, in another, and php in yet another, all in the same file. It’s amazing how often this is used (like a super-often example is markdown documents, which contains code highlighting for potentially dozens of languages in the same file, and those code blocks can contain ‘different’ code inside those blocks, like having elixir inside html inside markdown inside elixir doc blocks ^.^).

It all depends on the plugin.
As youknow,all these plugins are developped by simple independant developpers so it’s normal to find bugs.
No plugin is proviedby Microsoft.

That is if they are to handle sub-context support manually, but that is something that should be handled by the editor backend itself though.

1 Like

Atom ships with Tree-sitter now, which understands your code semantically rather than pretend to with regex (TextMate grammar). Syntax highlighting and auto-formatting embedded languages would theoretically be far superior.

There are no Tree-sitter parsers implemented for Elixir or EEx yet. But since VS Code hasn’t indicated support, developer experience on Atom may pull ahead once a parser is made.


That’s not really directly related to auto formatting, but I think here is a good place to publish this.
When you use vscode-elixir it really drove me crazy how commenting on interpolated elixir tags inside an .html.eex file broke through the complete syntax code.
So I just opened a PR to vscode-elixir that solves that problem by simple using the normal html multiline comment tags.


VS Code does support embedded languages:

1 Like

Ooo nice! It’s about time it does! I hope extensions take advantage of it without users needing to do manual configuration like that! :slight_smile:

I’ve been trying to modify the vscode-elixir-ls to use it all night, but no luck so far, if anyone knows of other extensions that take advantage of that feature let us know it’ll be helpful to see some examples. (I tried to mimic what Ruby extension does but didn’t work out very well)

1 Like


Yes, this is also driving me mad about the EEX formatting in VSCode.

I also found the embedded language support instructions and tried to figure out what was needed to support vscode-elixir-ls, but couldn’t figure it out…

Did you raise a bug on this with vscode-elixir-ls? Perhaps someone there has more idea?


For VSCode, I use the Prettier plugin for most filetypes but as stated earlier in this thread that breaks .html.eex files.

What I found works great is to install the Beautify plugin and configure it to only affect EEx:

  "beautify.language": {
    "js": [],
    "css": [],
    "html": [
      "HTML (EEx)"

If you are using ST3 you’ll want to use the HTML-CSS-JS Prettify plugin.

I still haven’t figured out how to get syntax highlighting or auto-formatting to apply to inline LiveView as the ~L sigil is treated as a normal heredoc string.

Hope this helps someone!