Avoid the creation of .formatter.exs on new projects

As I find it very important to keep our “Elixir Project Structure” clean,
so I would suggest to start a discussion about,
if we should try to avoid creating .formatter.exs on new Elixir projects.

I personally use in my projects just the following within my mix.exs file:

defp aliases do
  [
    format_all: "format \"mix.exs\" \"{lib,test}/**/*.{ex,exs}\""
  ]
end

Post which brought me to think about the project structure topic: pragdave.me

What’s the problem with deleting the file?

Nothing. But I want to discuss if it’s necessary to create it up first…

Personally, I prefer to keep this file, as it not only specifies which files to include in formatting, but also specifies which external or internal formatting rules I want to use to keep or omit parens.

3 Likes

Well, I guess quite a lot of people use the elixir formatter and would like to have a config for it. It’s way easier to delete the file if you don’t need it than to look up it’s supposed content if you want it.

3 Likes

Personally I could see the data in .formatter.exs being moved into e.g. mix.exs, but I doubt this to happen not that .formatter.exs is already part of many projects.

I won’t remove the purpose of .formatter.exs.
I just want to avoid its creation up front for new projects.

I would like to keep mix.exs with stuff only related to the project code itself, without cruft like file formatting. If anything then I would highly suggest using more of :env in application spec instead of config.exs.

@webuhu the problem arises when you want to have custom formatting like in Phoenix or any Ecto project. And as these is a lot of such projects then you will end with .formatter.exs anyway. So what is the point?

That simply does not make sense for me.

We have two use cases here:

  1. Wants to use the formatter
  2. Does not want to use the formatter

If there is no .formatter.exs, all the people who would like to use it, have to google for the supposed content of the file.

If someone does not want to use it, they can simply ignore the file or delete it.

This requested change creates a bigger amount of work for the usecase of the majority of users. While your “edge-case” requires little to no effort to archive the goal on your project.

4 Likes

@hauleth: My point is i would prefer to have the configuration of file formatting somewhere else,
as in the top level of our project structure. But of course it’s a minor desire.

I’m just thinking about keeping our project structure for newbies and new projects as clean as possible.

Or why have we removed the creation of the config folder …

I am a fan of Pragmatic Dave and I share some of this ideas. In this specific case however, it is my personal opinion that a formatter file does not hurt because this way, your team can have a custom formatter file in a public Repo and use it for all projects.

There is also the notion of mixing concerns. mix.exs files usually are concerned with dependencies (compile time or run time), and apps that add QoL to development (such as credo, for example). If you add formatting options to mix.exs, then should you not also add the configuration needed for all other mix deps (should you not also add credo configurations to the file since credo also has some formatting capabilities)? The line gets very thin very quickly.

I defend that one should have small projects, but you also need to understand that PragDave’s approach deviates a little bit from the community standards. In the end you really have to consider if the usage of the community standard satisfies the costs it implies.

If you want to help newbies, then my recommendation is to follow community standards because this way they will be able to benefit from the help of the entire community when they finally hit a wall.

If you opt for a custom approach to projects, then the community will have a harder time to help you and your team because your solution deviates from the standard everyone is used to working with.

When did this happen? Can you share?

2 Likes

Elixir 1.9 AFAIK.


From the release notes of the RC:

  • [mix new] No longer generate a config/ directory for mix new
1 Like

See http://blog.plataformatec.com.br/2019/04/whats-new-in-elixir-apr-19/ and https://github.com/elixir-lang/elixir/pull/8932

2 Likes

Agree, with that - it doesn’t hurt at all.
Same as starting a discussion never hurts at all.

As a first conclusion I see the formatter configuration doesn’t really fit into the community purpose of mix.exs.
And I’ve not any other quick solutions to this thing, which is really not a problem, right now on hand.