-
Notifications
You must be signed in to change notification settings - Fork 17.9k
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’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
proposal: html/template: add a formatter #69413
Comments
CC @robpike |
White space can be meaningful in HTML in ways that are not statically determinable. The most obvious way are tags like Most of the time it doesn't matter and you could get away with some rough heuristics, but you'd need some syntax to flag that a section of a template can't be reformatted for those rare times when it's important and you'd probably want |
@jimmyfrasche I’ll admit to rank ignorance about the details….but somehow or other prettier formats HTML in very opinionated ways and it is very widely used. |
It's fine almost all the time. When it's not, you need a way to mark the section that's not safe to format. The alternative is to not format that file at all, which is hard if everyone's editor is set to format on save and so on and no one would think to check if it's okay to format a file because why wouldn't it be? |
What are the 3rd party options here? Maybe https://github.com/a-h/templ ? I think templ doesn't support html templates from the std lib tough. |
Tossing my 2 cents into the ring. I've turned off formatting on most HTML files in my site because they break some functionality or another (most obvious example is Markdown content inside Sorry Josh :\ |
I don't actually understand what you're asking for. |
afaic, the proposal is to introduce a tool, likely a part of the Go binary, which would take a file like so: <h1>{{.PageTitle}}</h1><ul>{{range .Todos}}{{if .Done}}<li class="done">{{.Title}}</li>
{{else}}<li>{{.Title}}</li>{{end}}{{end}}</ul> and format it so it looks something like this: <h1>{{.PageTitle}}</h1>
<ul>
{{range .Todos}}
{{if .Done}}
<li class="done">{{.Title}}</li>
{{else}}
<li>{{.Title}}</li>
{{end}}
{{end}}
</ul> |
Keep in mind that HTML templates can contain both CSS and JS. |
There is a plugin for Prettier that I use: https://github.com/NiklasPor/prettier-plugin-go-template It's not always the best though. It sometimes gets confused. A challenge for this is gofmt just ignores line length altogether, but an HTML formatter typically needs to decide when to put things on a newline or not, unless you want it to be purely an indentation fixer. There are a lot of design decisions to make. |
With prettier-plugin-go-template, when I need to do something and the formatter keeps screwing it up or I need to do incomplete markup with opening and closing tags in separate templates, I will do something like:
|
If doing html (and everything else that goes with it) proves to be infeasible, there is a retrenchment available: format only the stuff completely inside the |
One other observation. The highest value (to my mind) is managing indentation. When using |
For html templates this project looks already pretty good: djLint. For yaml templates (e.g. kubernetes helm) this seem like a open challenge to implement. |
I just ran djLint on my codebase. It appears that it formats Go template actions by destroying all indentation:
|
You said you wanted a single unified vision.... |
Proposal Details
Go was a trailblazer of standardized, no-knobs code formatting. Yet one of the major components of the standard library--one in which I've personally written tens of thousands of lines of code--has no usable formatter. (There's one abandoned open source one that has showstopper bugs. And prettier is oblivious to the Go templating code, with predictable results.)
The surface area would be:
I propose that the details of the formatting be left up to the Go team (or whoever steps up to do the implementation), maybe after a preference-gathering round. I care about the details...but I care WAY more that there be a single unified vision behind it and that it be standardized.
The text was updated successfully, but these errors were encountered: