That would not explain that because LS uses a separate _build. Plus, in all cases, simply restarting the server should have been enough.
josevalim
Creator of Elixir
c4710n
This indeed explains a problem that has puzzled me for a long time.
In Emacs, I use an external system process (which will call mix format) to format Elixir code. After each formatting is completed, and I input recompile() in IEx, I find that the execution result of the code is not updated. I have to reopen IEx.
Today, I tried v1.18 with :auto_reload, and the problem is finally solved. Thanks!
Also, another question: why isn’t :auto_reload set to true by default? Or is there a plan to make it true by default?
3
maikelthedev
general-CbIC
I enjoyed the new ExUnit’s parameterize feature. Thanks! 
It helped to refactor tests and increase coverage.
I also found a fun hack to avoid older Elixir versions’ CI test failures. Maybe it will be useful for some of you 
use ExUnit.Case,
parameterize: [
%{some_option: 1},
%{some_option: 2},
%{some_option: 3}
]
setup_all do
if Version.match?(System.version(), ">= 1.18.0") do
[]
else
# One of the `parameterize` options for older Elixir versions
[some_option: 1]
end
end
2
josevalim
Creator of Elixir
The problem you described is solved without auto_reload: true, using recompile() now will work as it will see the changes to disk (it did not before, which is why you were puzzled). auto_reload just makes it so applies immediately.
We may make it the default in the future, we are trialing it, but changing code live could also bring its own issues. Should a change in the editor cause a long running script in IEx to now run a new code?
7
c4710n
Thank you for explaining this issue again. Otherwise, I would have misunderstood the solution.
(I have to admit, my question at that time was just something I asked offhand. But your question has sparked some thoughts in me.)
Maybe, we shouldn’t.
If we step out of the context of Elixir and imagine a typical OS process, there are a few ways I know to update its code: completely restarting the process, hot-reloading a dynamic library, or some other methods I don’t know. However, regardless of the method, there is always a clear step that explicitly requires the OS process code to be updated.
If auto_reload: true is set as the default behavior, the code running within a process implicitly changes along with the source code. That’s not good, generally.
And, let developers explicitly set IEx.configure(auto_reload: true) themselves, so that when they encounter some unexpected behavior, they can consciously consider the underlying cause about :auto_reloead.
Also, I can think of a quote that might fit here as well - “Explicit better than implicit”.
So, I think current default is good. Don’t change it. 
4
josevalim
Creator of Elixir
v1.18.1 is out addressing the feedback received so far: Release v1.18.1 · elixir-lang/elixir · GitHub
1. Enhancements
- [Kernel] Do not emit type violation warnings when comparing or matching against literals
- [Kernel] Do not validate clauses of private overridable functions
2. Bug fixes
Elixir
- [Code.Fragment] Ensure
Code.Fragment.container_cursor_to_quoted/2with:trailing_fragmentparses expressions that were supported in previous versions - [Kernel] Do not crash when typing violation is detected on dynamic dispatch
- [Kernel] Properly annotate the source for warnings emitted by the compiler with the
@fileannotation - [Kernel] Properly annotate the source for warnings emitted by the type system with the
@fileannotation - [Kernel] Remove
:no_parensmetadata when using capture with arity on all cases - [Kernel] Ensure diagnostic traces are kept backwards compatible
ExUnit
- [ExUnit.Case] Ensure async groups do not run concurrenly while the test suite is still loading
- [ExUnit.Case] Ensure
--repeat-until-failurecan be combined with groups
Mix
- [mix compile.elixir] Store compilation results if compilation fails due to
--warnings-as-errors - [mix deps.loadpaths] Add build lock
- [mix escript.build] Ensure build succeeds when protocol consolidation is disabled
- [Mix.Shell] Ensure encoding is properly respected on Windows and Unix systems
12
barryp
Hi, I’ve just upgraded to 1.18.0 and subsequently 1.18.1 and find that my tests won’t run in either. I get the message “cannot add module named *** to test suite after the suite starts running”. Looking at the ExUnit source code this was added as part of the work for Parameterized tests for 1.18.x
Changing
use ExUnit.Case, async:
to
use ExUnit Case
fixes the issue, but is it expected that tests which ran fine in 1.17.x should no longer run?
0
restlessronin
josevalim
Creator of Elixir
Hi @barryp, can you provide a mechanism to reproduce the error? Then I can take a look at it. But, if I remember correct, before we added that warning, it meant the test cases added later were being fully dropped, i.e. they did not run at all, and now we are being more vocal about it instead of letting it happen silently. If we can reproduce it, I would be able to confirm it.
0