Hmm … config is just … config, so “not much” happens in them. It’s almost as same as json or yaml configuration files except that you can add some extra Elixir code to them. The biggest thing about config files is how they works across environments and that’s almost all. All the basics are covered in Config documentations.
Do you mean code formatting? It’s as same as in any other source code file, see the documentation for mix format task.
Almost everything - it’s easier to say what to put to them. Basically all you need is fetching the OS environment variables and using config_env() - both are well covered in Config documentation.
What “responsibilities” are you referencing to? Simply read the documentation what you are able to configure and use the ones you need. There are no “business logic” inside config or something like that. Simply configure your app and dependencies as you do in json or yaml files, but with a bit more of flexibility for example to fetch some data (like above in OS environment variables) and use them for configuration.
Best practice is rather to follow community standards as it’s easier for others to read your code. However nobody is limiting you what and how you do in your pet projects. If you want name them as you want. The default ones should be clear enough, so most people simply don’t touch configuration file names i.e. there is no need to do that.
Elixir does not have a framework which forces you to do something in specific direction, but gives you a good defaults. As above usually nobody is changing them. They are in config directory in both pet and huge business projects as keeping them in well known default location makes the most sense.
Simply you are passing a file name of file you want to import. There is no magic here except that you cannot import things in runtime.exs (also explained in Config documentation).
The materials are created when needed. If someone is asked to deploy a phoenix app to AWS then having production knowledge the tutorial is shared. Sometimes people have a problem finding something in documentation, but as above changing config naming is not common. Not much people were ever thinking about that and therefore there are not much resources about it. Same is for a database. By default in most projects PostgreSQL is more than enough. You are free to learn about other databases, but again if you don’t need it then you don’t have to learn about it.
Yes it is, but not so detailed. As long as you follow documentation and forum you should be fine. For most cases there are tools to help you like credo.
Possibly related:
