What do you mean? Without ginject

  @ms Application.compile_env(:app, [__MODULE__, :mapset_module], MapSet)

  def new_mapset(x) do
    @ms.new(x)
  end

And test config like

config :app, MyModule,
  mapset_module: TestMapSet

But with ginject

  use Ginject
  service MapSet, as: MS

  def new_mapset(x) do
    MS.new(x)
  end

And

config :ginject, Ginject.DI,
  strategy: Ginject.Strategy.BehaviourAsDefault,
  services: [
    {MyModule, [
      %{service: MapSet, impl: TestMapSet}
    ]}
  ]

What’s the difference?

With ginject, in most cases you only need two lines of configuration:

# config.exs
config :ginject, Ginject.DI, strategy: Ginject.Strategy.BehaviourAsDefault

and in test:

# test.exs
config :ginject, Ginject.DI, strategy: Ginject.Strategy.Mox

The BehaviourAsDefault strategy uses the behaviour’s own module implementation as the default service.

For example, a typical service in my project looks like this:

defmodule MyProject.ServiceA do
  @callback foo() :: any()

  @behaviour __MODULE__

  @impl true
  def foo do
    ...
  end
end

You only need to configure BehaviourAsDefault like:

services: [
  {MyModule, [
    %{service: MapSet, impl: TestMapSet}
  ]}
]

if you want a custom override for a specific service used by MyModule.

If you prefer to separate behaviour definitions from implementations, you can also define your own strategy, for example based on naming conventions.

Testing

In the test environment, the Mox strategy automatically creates mocks for you, and you can set expectations directly on them.
You can see an example here

Without ginject, you typically need to define configuration entries like:

config :app, MyModule, mapset_module: TestMapSet

for every module and every injected service.
This grows quickly in large codebases, and you must duplicate these configs in both config.exs and test.exs, plus define mock/test implementations somewhere.

I also find

service MapSet, as: MS

much easier to read and write than:

@ms Application.compile_env(:app, [__MODULE__, :mapset_module], MapSet)

and then calling:

MS.new(x)

versus:

@ms.new(x)

Additionally (though I’m not 100% certain), using module attributes may cause you to lose autocompletion and jump-to-definition features in editors.

Edit:

I realize the docs could be clearer and needs some more refinement - I’m working on it!

That applies only to the Mox strategy. The library itself provides dependency resolution and injection functionality, independently of Mox.

Yes. I’m considering one based on naming conventions. Other ideas are definitely welcome.

I’m not entirely sure I understand. Could you elaborate a bit more on this?

Good point, thanks for catching that. I’ll fix it as soon as possible.

As for the macro name, I like inject, but I want to think a bit more about this.