It looks like 2.12 unifies fmt/lint under the hood: https://github.com/pantsbuild/pants/pull/14903 How will this tutorial change to account for that? https://www.pantsbuild.org/docs/plugins-fmt-goal#3-create-fmt-and-lint-rules Has anyone looked at that? ie, can I skip writing a lint rule, and just write a fmt rule?

If you're writing a language formatter, you get the lint goal for free, and I think most/all of the formatter codes have been updated to that (example: https://github.com/pantsbuild/pants/blob/main/src/python/pants/backend/cc/lint/clangformat/rules.py) However, something I ran into yesterday is that if you have a tool that does best-effort lint fixes/formatting, but still has issues that are strictly lint, you need to write separate lint + fmt components, otherwise you suppress valid lint warnings. Seems obvious, but it was surprisingly surprising when I noticed it. So, in my case, I had to revert back to the classic way of doing this.

if you have a tool that does best-effort lint fixes/formatting, but still has issues that are strictly lint, you need to write separate lint + fmt components

Oh this is interesting. Some notes: • You probably want to have the lint rule do just lint things (if possible) so you don't duplicate the work or output • You probably want it to use a different subsystem/option scope or else the output might duplicate the name

ansible-lint

will do this. It's primarily a lint tool, but I'm adding the ability for it to reformat / update files. It will only be able to fix a subset of issues however.

Yeah it was really satisfying removing all the duplicitous code from our formatter 😈

Cleaning up legacy stuff is very satisfying. 👼 (as it should be)

Hahah, @proud-dentist-22844 That was the exact tool I was referring to