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.
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?
I’m curious why VSCode has such issues formatting eex files? In Atom.io 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 Atom.io? Formatting works as expected, syntax coloring works as expected, intellisense works as expected, etc…
That sounds like a really bad misdesign if so… Even the ancient vim and emacs have primary buffer types and sub buffer types (that Atom.io 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 Atom.io even though its the same author when Atom.io 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 Atom.io 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. Atom.io 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 Atom.io a try, though I really hope that @specs display from the elixir-ls plugin gets added someday. ^.^
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.
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.
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)
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?
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.
