The formatter code mod will use in-project formatting by default. If that doesn't work as expected and raises an error, the code mod will fall back to basically this:
read .formatter.exs into a keyword list, let's call it opts
run Code.format_string! with opts as formatter options
This is problematic, as Code.format_string! does not understand all options allowed in the formatter dotfile. Here's a list of the options that the dot-formatter supports but the function doesn't: https://hexdocs.pm/mix/Mix.Tasks.Format.html#module-formatting-options. Most importantly, plugins and import_deps are not supported. mix format reads from the dotfile and then applies a few transformations to it, e.g. this, thus bringing it into a format that Code.format_string! supports.
I'm not sure what to do about this: the fallback is currently mostly incorrect and is likely very hard to fix. Should we just shell out to mix format path/to/file.ex instead? Or try to evaluate / resolve all options supported in the formatter dotfile?
The formatter code mod will use in-project formatting by default. If that doesn't work as expected and raises an error, the code mod will fall back to basically this:
.formatter.exsinto a keyword list, let's call itoptsCode.format_string!withoptsas formatter optionsThis is problematic, as
Code.format_string!does not understand all options allowed in the formatter dotfile. Here's a list of the options that the dot-formatter supports but the function doesn't: https://hexdocs.pm/mix/Mix.Tasks.Format.html#module-formatting-options. Most importantly,pluginsandimport_depsare not supported.mix formatreads from the dotfile and then applies a few transformations to it, e.g. this, thus bringing it into a format thatCode.format_string!supports.I'm not sure what to do about this: the fallback is currently mostly incorrect and is likely very hard to fix. Should we just shell out to
mix format path/to/file.exinstead? Or try to evaluate / resolve all options supported in the formatter dotfile?