I ran into this issue and found the PR, then investigated why I was still getting the problem after there had already been a fix.
With Elixir 1.12 the meaning of Code.ensure_compiled/1 changed to mean that the compiler can continue compiling without this module, while Code.ensure_compiled!/1 took on the responsibility of having the compiler wait until the missing module is compiled before continuing.
From the docs for Code.ensure_compiled/1 v1.12:
Similar to ensure_compiled!/1 but indicates you can continue without said module.
While ensure_compiled!/1 indicates to the Elixir compiler you can only continue when said module is available, this function indicates you may continue compilation without said module.
The docs for Code.ensure_compiled/1 for v1.11.4 reads:
If the module is already loaded, it works as no-op. If the module was not compiled yet, ensure_compiled/1 halts
the compilation of the caller until the module given to ensure_compiled/1 becomes available or all files for the current project have been compiled. If compilation finishes and the module is not available, an error tuple is returned.
I'm not really sure how to write a test for this. The behaviour I have that found this problem has roughly 50 callbacks (planning to break it up into smaller behaviours.) so perhaps creating a behaviour that takes a long time to compile will duplicate the issue.
I have kept the behaviour the same, raising the same error as before, so the existing tests pass.
This PR is a follow up of https://github.com/dashbitco/mox/pull/17
I ran into this issue and found the PR, then investigated why I was still getting the problem after there had already been a fix.
With Elixir 1.12 the meaning of
Code.ensure_compiled/1
changed to mean that the compiler can continue compiling without this module, whileCode.ensure_compiled!/1
took on the responsibility of having the compiler wait until the missing module is compiled before continuing.From the docs for
Code.ensure_compiled/1
v1.12:The docs for
Code.ensure_compiled/1
for v1.11.4 reads:I'm not really sure how to write a test for this. The behaviour I have that found this problem has roughly 50 callbacks (planning to break it up into smaller behaviours.) so perhaps creating a behaviour that takes a long time to compile will duplicate the issue.
I have kept the behaviour the same, raising the same error as before, so the existing tests pass.