add support for context_options: warn instead of error, and specify allowed couplings

[jonklein]

First of all, thank you for this library - I had been considering building something similar myself, but now I don’t have to.

This pull request adds two pieces of functionality around the context boundary detection, with the goal of helping more gradual enforcement for existing projects which might have a lot of inter-context dependencies. Both are configured via a new “context_options” key in the contexted config.

First, add support for a level config. If this key is set to :warn, the compiler will emit a warning instead a compile-time exception. It also adds the line/file to the emitted message.

Second, add a way to configure “allowed” couplings via the allow config. If a coupling is allowed, then no warning/exception will be triggered. This key is a list of {calling_context_module, [allowed_called_module, ...]}.

The following example shows a configuration for two contexts where couplings trigger warnings rather than exceptions, and MyApp.Documents is explicitly permitted to call MyApp.Accounts.

config :contexted,
  contexts: [
    MyApp.Accounts,
    MyApp.Documents
  ],
  context_options: [
    level: :warn,
    allow: [
      {MyApp.Documents, [MyApp.Accounts]}
    ]
  ]

[itamm15]

Hi @jonklein! Thank you for PR :) We will review it soon!

[itamm15]

Hi @jonklein! First of all, we would like to thank you for your contribution! We discussed this matter and would like to propose another way to handle the codebase migration to Contexted. Here are two potential solutions/enhancements:

1. Add a .context-ignore file: In this module, we could define the modules and functions that interfere in the following way:

[
  {ModuleA, [{:func_name, :arity, [...contexts]}]}
]

where:

1. ModuleA is the module name where the function originates,

2. func_name is the function name,

3. arity is the number of arguments the function takes,

4. contexts is the list of contexts from which the function is called (but should not be).

5. Fine-grained context definitions: Currently, we define all of the contexts in the app within config.exs. The idea here would be to adopt a more fine-grained approach:

config :contexted,
  contexts: [[MyApp.Account, MyApp.Book], [MyApp.Location, MyApp.Account]]

In the above example, we would enforce cross-referencing checks only between MyApp.Account and MyApp.Book, and between MyApp.Location and MyApp.Account. Regarding config_level, we could define one, either per whole Contexted, or per specific, nested contexts.

We would like to hear your thoughts on these proposals. If you have any questions, please let us know! :)