Proposal: Allow custom options for formatter plugins

[Bart Blast]

Problem

Currently, formatter plugins cannot receive custom options. This limitation becomes problematic in scenarios where plugins need configuration to determine their scope or behavior.

Real-world Example

The Phoenix LiveView formatter plugin formats all ~H sigils in the codebase. However, ~H sigils are general-purpose and can be used by any library (e.g., Hologram uses them for its own purposes). This leads to issues:

• When Hologram codebase is formatted, the LiveView formatter raises errors because it incorrectly attempts to parse Hologram's ~H sigils as HEEx templates
• Currently, there's no way to tell the LiveView formatter which paths should be formatted and which should be ignored

Proposal

Allow specifying custom options for formatter plugins in .formatter.exs:

Current syntax:

[

  # ...

  formatters: [MyLib1.Formatter, MyLib2.Formatter],

  # ...

]

Proposed syntax:

[

  # ...

  formatters: [MyLib1.Formatter, {MyLib2.Formatter, a: 1, b: 2}],

  # ...

]

Benefits

1. Plugins can receive configuration to customize their behavior
2. Solves the LiveView vs Hologram formatter collision by allowing users to specify which paths should be formatted by which plugin
3. More flexible and configurable formatting system overall

Implementation Notes

• The formatter would pass these options to the plugin's formatting functions
• Plugins not requiring options can still be specified using the current syntax
• Backward compatible change - existing formatter configurations would continue to work

[Bart Blast]

Related Phoenix.LiveView formatter pull request: https://github.com/phoenixframework/phoenix_live_view/pull/3654

[José Valim]

All options you pass at the root are already received by the formatter.

In this case though, I would really recommend picking another sigil though. Two sigils of the same name cannot coexist and you would have have to import each accordingly.

José Valim

https://dashbit.co/

--
You received this message because you are subscribed to the Google Groups "elixir-lang-core" group.
To unsubscribe from this group and stop receiving emails from it, send an email to elixir-lang-co...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/elixir-lang-core/504b9140-c09a-4937-a330-4587e5965efcn%40googlegroups.com.

[Bart Blast]

Just wanted to close the loop on this thread - after discussing with José in Phoenix LiveView PR: https://github.com/phoenixframework/phoenix_live_view/pull/3654 I'll be changing Hologram's template sigil from ~H to ~HOLO. While I see sigils as regular functions that different libraries should be able to use independently (like sigil_H/2), and have some reservations about letting LLMs influence architecture decisions, the practical benefits of distinct sigils make sense.