skwidbreth
When I’m working on a mix app, I’ve noticed that changes that I make to code in my app’s dependencies are observable in the dev environment after recompiling the dep, but not in the test environment. Is this an intentional part of mix’s design? If so, is there a mix-based workaround?
Here’s an example scenario… I’m working on an app, doing some basic red-to-green testing. I’m having trouble debugging my app’s integration with one of its dependencies, and want to throw some IO.inspects into the dep to help me debug. I add the debug code, recompile the dependency, and run the tests again, but the code I’ve added has no effect. However, if I remove the directory at _build/test/lib/my_dep and run the tests again, the changes are present.
Steps to replicate:
- get a dependency with
mix deps.get my_dep - compile the dependency with
mix deps.compile my_dep
At this point, a compiled version of the dependency will appear at my_app/_build/dev/lib/my_dep, but not at my_app/_build/test/lib/my_dep
- I run tests with
mix test- the compiled version ofmy_depnow appears atmy_app/_build/test/lib/my_dep - I make a change to a file in
my_app/deps/my_dep, compile the dep withmix deps.compile my_dep, and run the tests again
The change that I’ve made to the dependency is reflected in the _build/dev/ version, but not in the _build/test/ version - so if I run the tests again, the change does not take affect, nor is it observable if I start an iex session via MIX_ENV=test iex -S mix (though it is observable if I start iex in the dev environment).
From walking through this step-by-step, it’s become evident to me that deps are compiled differently for different environments . If there’s no other way around this, it’s not a big deal - I just have to run $ rm -rf _build/test/lib/my_dep when I make changes… but I’m interested in learning more about this aspect of mix’s design, and if there’s a way that I can recompile a dependency specifically for the test environment.
Trending in Questions
Other Trending Topics
Categories:
Sub Categories:
Forums
Popular Tags
- #ecto
- #liveview
- #troubleshooting
- #learning-elixir
- #library
- #deployment
- #erlang
- #testing
- #genserver
- #mix
- #absinthe
- #remote-other
- #otp
- #plug
- #how-to-question
- #macros
- #postgres
- #elixirconf
- #channels
- #exunit
- #discussion
- #code-sync
- #podcasts
- #javascript
- #onsite
- #dialyzer
- #docker
- #authentication
- #umbrella
- #full-time-contract
- #podcasts-by-brainlid
- #ecto-query
- #elixirconf-us
- #ai
- #blog-post
- #elixir-ls
- #phoenix_html
- #iex
- #graphql
- #genstage
- #websockets
- #supervisor
- #advent-of-code
- #distillery
- #processes
- #api
- #forms
- #metaprogramming
- #hex
- #security










Showing Posts 1 to 3- Show Best Posts
- Show All (oldest first)
- Show All (newest first)
NobbZ
You are not supposed to make any changes in
deps, if you really have to, then you need to recompile the deps manually for each environment, eg.MIX_ENV=test mix deps.compile.skwidbreth
I definitely appreciate the fact that making changes to deps is somewhat taboo, but I find that it is helpful for my development process. Thanks very much for the tip! I didn’t realize that would work, makes sense.
axelson
While developing you could also try changing the dependency to:
But in either case you have to be very careful to not overwrite any changes you make and I wouldn’t commit code that includes a path dep in deps. But I have found this technique useful for testing changes locally.