Move Phoenix.Endpoint compile time configuration from `config.exs` to `__using__`

Currently Phoenix.Endpoint relies on some compile time configuration options from config.exs file. While it works, it needlessly pollutes configuration file, and as a result it will end in sys.config for no reason. Instead it should be provided inline within MyApp.Endpoint directly, like in Ecto 3.0 when the adapter specification was moved from config to the Repo itself.

What is your opinion on such change?

Splattering configuration all over the source is an absolute “NOPE” from me. Even the Repo way of doing it is an anti-pattern in this regard. Such way of doing things creates extra friction and adds WTFs due to additional cognitive load. I’d hate for Elixir to become a quirky niche tech that’s only understood by a small hardcore community due to the need to handle such dark magic like configuration potentially being everywhere in the source.

While I do agree on the sys.config part, I believe we should try really hard to have any and all configuration in one fixed directory in the project. But that circles back to the huge discussion on built-in standardized Elixir configuration mechanisms for (1) compile-time, (2) boot time and (3) runtime configuration, where the jury is still out.

It is not quirky IMHO. Just compile-time dependencies should be stored in code, not in configuration. If such approach would be more popular then it could improve such things and make Phoenix.LiveReload to not fail on configuration change (or do it less often). I do not see how:

config :my_app, MyApp.Endpoint,
  render_errors: [view: MyApp.ErrorView, accepts: ~w(html), layout: false]

Is more readable than:

defmodule MyApp.Endpoint do
  use Phoenix.Endpoint,
    render_errors: [view: MyApp.ErrorView, accepts: ~w(html), layout: false]

While with other options, like :debug_error we could dispute whether it would be better to keep them in config (as it would be easier to set them only in development), but IMHO at least :render_errors should be within module itself, not in application configuration.

1 Like