What to do with Elixir/Phoenix Build warnings

Questions / Help
1

Every project i make in Elixir/Phoenix results in after a while in a descent amount (from 10 to 50) build warnings.

This is because of warnings in the packages i pull in mostly, i would like to know from more experienced programmers, what do you do with them? Just ignore the warnings?

i worked in a company where Java devs were very much fixing EVERY warning that came up with maven, and it was the best most stable code base ever, I worked in a company where Java devs ignored warnings and it was more of a mess.

What’s the normal operation in the Elixir/Phoenix world? Do you ignore them or skim over them quickly? Or try to fix them if possible if it’s in your code?

Thanks

2

Unfortunately, there is nothing you can do about warnings coming from packages, you have to just ignore them and hopefully they get fixed (and you can always file a bug report). When they come from your own code the general consensus is that they should absolutely be fixed—this is encouraged by the language by having no (built-in) way to ignore warnings. You can force this in your own projects by compiling with the --warnings-as-errors flag. Intelligently, this flag will not cause the build to fail for warnings coming from packages which, again, you can do nothing about.

3 Likes
3

This is normal in a lot of languages, not only Elixir, and I agree it’s annoying.

Best course of action is to fork them and offer the changes as PRs. Authors are usually responsive.

If they are not you either ignore it or just keep the fork as a new version for your org only.

6 Likes
4

Just to be clear with OP here that “fixing” means upgrading the packages to versions that don’t have the warnings (usually the “fix”). These warnings that pop up usually are solved with upgrades of said libraries (what OP called packages).

Other than that, spot on.

5

It is a good sign whether those packages are actively maintained. I will start planning to migrate off them if some packages are showing sign of negligence.

6 Likes
6
  • Packages might look abandoned just because they are stable and done.
  • Newer Elixir versions may cause warnings due to deprecation, however these deprecated functions will only be dropped in a major version (and there are no signals there will be another major version). As a result there is immediate risk.
  • Some maintainers are not aware new versions of Elixir raise warnings. Simply nudge them (on multiple platforms as Github notifications are known to be missed)

But granted: the broken window effect might be real. So let’s all stay on top of it and help lib maintainers!

4 Likes
7

Agreed. Elixir libraries usually do a decent job of not to cause frivolous deprecations. I wish the following can be reversed, though:

warning: Logger.warn/1 is deprecated. Use Logger.warning/2 instead

It is harmless, the cost to maintain backward compatibility is negligible, so why bother printing a warning.

1 Like
8

Fair enough indeed. For that we have the Version module and then Code. Making sure newer versions don’t raise warnings is one sign that the maintainer is paying attention and that the package is not abandoned.

9

True, but it can’t be applied the other way around so the statement might be misinterpreted.

Not sure what Version and Code have to do with it…?

10

You can check Erlang / Elixir versions and have conditional Code calls in order to avoid warnings.

I admit it’s been a while since the last time I had to do this. Ever since then I just push for periodic upgrades and rarely had to patch a dependency.