Importing formatter opts is manual labor

File this in the very-small-nits folder :slight_smile: but does anyone else feel that formatter opts should be imported by default, and ignored as a explicit option.

My situation is I have a little DSL, which has several functions in it’s locals_without_parens, (which are also being exported) in it’s .formatter.exs. 99.99% of the time when want to depend on this dsl package, I also want it’s formatting rules. Currently, this means I need to modify the parent .formatter.exs. Not the end of the world, but it seems like a unnecessary install step. More than once I’ve either forgotten this step, or messed up the syntax by mistake. This is my own dependency, but I think it’s even a bigger issue for something on hex, when I really just want to add it to deps and go.

The formatter supports a mechanism where you can import the locals_without_parens from a dependency: https://hexdocs.pm/mix/Mix.Tasks.Format.html#module-importing-dependencies-configuration

3 Likes

right. I’m arguing that I should not have to use import_deps: if the dependency has export:

Some DSLs are also very general, like Ecto Migration that uses words like create, add, etc. Those may have undesired effects in your project and you want to import those only in some special circumstances, such as under the priv/repo/migrations directory. I would never want those to be always imported.

But ultimately, it is your application. You should have control over how the formatter acts. Bringing a dependency should not affect the formatter, configuration or other parts of your project unless you explicitly say so.

2 Likes