silviurosu
Elixir 1.11 Application boundaries and umbrella apps
I migrated my app to Elixir 1.11 and I receive some warnings that I need to fix for the build to pass on CI.
I have a bunch of umbrella applications. Since all umbrella applications depend on common libraries I have decided to have an umbrella where I list all the common dependencies and the other umbrella to depend only on this one. This worked fine prior to Elixir 1.11. Now it seems that all the dependencies need to be listed as direct child not sub-child.
warning: Jason.encode!/1 defined in application :jason is used by the current application but the current application does not directly depend on :jason. To fix this, you must do one of:
1. If :jason is part of Erlang/Elixir, you must include it under :extra_applications inside "def application" in your mix.exs
2. If :jason is a dependency, make sure it is listed under "def deps" in your mix.exs
3. In case you don't want to add a requirement to :jason, you may optionally skip this warning by adding [xref: [exclude: Jason]] to your "def project" in mix.exs
Found at 3 locations:
....
Elixir release readme says:
This new compiler check makes sure that all modules that you invoke are listed as part of your dependencies, emitting a warning like below otherwise
But I would not want to copy paste all common dependencies since it will be overkill to maintain and upgrade all dependencies. How can I fix this warning without moving my common deps (50+) to each umbrella app??
Most Liked
mindreframer
It’s really sad when valued and well-intentioned people clash about a misunderstanding.
Opinions are dime a dozen, and I guess due to lots of quite upsetting things happening right we might be quicker than usually to give harsher feedback than needed. I really think AndrewDryga meant no harm and his comment is based on his personal (frustrating) experience. He did not claim absolute correctness and made an open assumption that EllxirLS did not work as expected for his codebase. Because well… It was a confusing experience and one has a right to express his/her frustration. I hope we stay true to core values in the Elixir community and don’t let this misunderstanding grow out of proportions. We need every bit of support and “good vibrations” in current times.
Hope this comment did not offend anyone and gave a bit different perspective to the whole situation

josevalim
This is unfair. The fact it is not working for your codebase does not mean it is overall an issue for large codebases. It may even be an issue specific to your application, or specific to Elixir, especially because the feature it is emitting warnings on is fairly new to Elixir.
axelson
If you could create a sample repository that demonstrates the errors and submit it as an issue on https://github.com/elixir-lsp/elixir-ls/issues that would be appreciated.
josevalim
What you have posted is much more valuable to everyone in this thread. There are issues you pointed that others can contribute and work on and, most importantly, of all the issues that you linked, there is active maintainer feedback.
It is fine to say that it doesn’t work for yourself and the complex structure you have right now, but extrapolating that to all projects based on your data point is definitely not ok. As I always say, for a fairer assessment, I recommend you to put yourself in the shoes of the maintainers for a couple months, help people on the issues tracker, Slack, in the Forum, and then you will certainly have a better assessment and appreciation for the work being done.
NobbZ
Instead of copy pasting all 50+ of so called common deps, only add those handful to each project you actually use directly.
Sounds like a good opportunity for a some housekeeping.







