Do not generate config/config.exs for mix new

[josevalim]

mix new is mostly used for libraries and libraries should be actively discouraged of defining (because it is global) or using entries (as it only applies to the library) in config.

[ericmj]

I am not sure about this because config is where we define test or dev specific configurations. I think libraries are already discouraged of using config for other purposes because the config is not used when the library is used as a dependency.

[josevalim]

I think libraries are already discouraged of using config for other purposes because the config is not used when the library is used as a dependency.

There is nothing explicitly discouraging them though. It is only discouraged once you get to know that your own config is not shared.

Removing the config can also help libraries define defaults in the application definition in mix.exs, which very few do. For test specific config, you can do it in the test_helper?

[ericmj]

There is nothing explicitly discouraging them though. It is only discouraged once you get to know that your own config is not shared.

Maybe I am missing some context here. Is it discouraged other than that the config is not shared?

Removing the config can also help libraries define defaults in the application definition in mix.exs, which very few do.

I don't think removing config will help do that because you cannot use config to define application defaults. Nothing is changing for people that doesn't already define application defaults in mix.exs.

For test specific config, you can do it in the test_helper?

I think the application is started before test_helper runs, so it will work for some cases but not all.

[Eiji7]

I see why this issue was created. When I started with Elixir I though that config directory is a right place. I don't think that only removing config directory is good enough here.

Doing it standalone could even give confusion to others. Instead of think: Where is the right place to declare configuration? people can look When I could place documentation? and once they would find any mention/project about config directory then it would be even more confused: Why I did not have this directory?, Should I run more commands for this? and Did I forget about something like --add-config option? - I could imagine questions like that.

How about create 2nd generator for library mix new.library? I believe that we can add more things to it like for example on from hex.pm site:
https://hex.pm/docs/publish#example-mixexs-file

[josevalim]

Maybe I am missing some context here. Is it discouraged other than that the config is not shared?

My point is that if you are writing your first library, there is nothing saying that config are discouraged and there is nothing necessarily saying that configs are not shared. And even if we say so, the relationship "configs are not shared" == "config bad" is not clear either.

I don't think removing config will help do that because you cannot use config to define application defaults. Nothing is changing for people that doesn't already define application defaults in mix.exs.

And that is usually a sign of bad configs, so I would treat this is a 👍 but we will only know for sure if we try.

[ericmj]

I am still having hard time understanding what this is trying to achieve.

Do we want more people to learn about and use application defaults? Are buggy libraries being released because people don't realize that config.exs is not shared? Do we wan't discourage config.exs in general because mix.exs and release configs will replace it in the future?

People that don't know about the mix.exs config aren't using application defaults. Removing config.exs will not make them automatically learn about mix.exs or application defaults.

[josevalim]

We want to get people to stop using Application.get_env in general to configure their own libraries.

Are buggy libraries being released because people don't realize that config.exs is not shared?

Also yes.

Do we wan't discourage config.exs in general because mix.exs and release configs will replace it in the future?

It is not about releases. Just to discourage config.exs altogether.

People that don't know about the mix.exs config aren't using application defaults. Removing config.exs will not make them automatically learn about mix.exs or application defaults.

I agree. But it won't make it worse either.

[NickNeck]

In my opinion, this change could point people in the right direction. I have updated my library after reading this.

[whatyouhide]

I am also in favour of this. How can we move the discussion forward, and either do it or not? :)

[brodeuralexis]

I too am in favour of this, but I believe more should be done to emphasize good practices, but here are some of my ideas and uncertainties towards this issue.

Do we want a dedicated section about authoring libraries in the documentation ?

If one were to implement this, should it be as a new generator (i.e.: mix new.library my_lib) or a flag (i.e.: mix new my_lib --lib or mix new my_lib --library) like it is done for the --sup option ?
Upfront, I think the flag approach will be simpler to implement, but I like the explicitness or new.library.

Do we want a new key in Mix.Project that will disable the hex.publish task like npm's private configuration option (without introducing breaking changes) ? Coupled with a good error message, this could help explain decisions concerning libraries.

[josevalim]

We already have a guidelines page for libraries in our guides. I also don’t want to include new generators or options because giving the user choices upfront is not necesssrily helpful and if they need a configuration file, they can just create one, the minimal config is only 1LOC. -- *José Valimwww.plataformatec.com.br <http://www.plataformatec.com.br/>Founder and Director of R&D*