[Proposal] --return-errors should be propagated to Mix.Tasks.Deps.Compile

[Guilherme Duarte]

Hello,

Proposal:

In order to facilitate the implementation of development tooling, such as elixir-ls, I propose the propagation of the --return-errors flag from Mix.Tasks.Compile to Mix.Tasks.Deps.Compile.

With this,  it would be possible to report diagnostic errors during dependency compilation.

With the current behavior, the mix compile --return-errors task does an early exit when dependency compilation fails, making it extremely hard to report error reasons.

This behavior change would be especially helpful when path dependencies exist.

Proposed Implementation:

In order to achieve this, the flag should be passed down from Mix.Tasks.Compile -> Mix.Tasks.Loadpaths -> Mix.Tasks.Deps.Loadpaths -> Mix.Tasks.Deps.Compile.

Mix.Tasks.Deps.Compile.compile should then accumulate the diagnostics messages returned by Mix.Tasks.Compile for each compiled dependency, and the returned values propagated back up call tree to be reported by the original task invocation (mix compile --return-errors)

Thanks for considering this! 

[José Valim]

Quick question: how would the errors in mix deps.compile be used in the editor? How could that be useful?

Also note that we won't be able to do this for all dependencies... so for dependencies the best choice may be to capture stderr.

--
You received this message because you are subscribed to the Google Groups "elixir-lang-core" group.
To unsubscribe from this group and stop receiving emails from it, send an email to elixir-lang-co...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/elixir-lang-core/03daf960-dc81-4d76-b9b5-015d2e47e72bn%40googlegroups.com.

[Guilherme Duarte]

Hey José,

Thanks for the quick response.

The mix deps.compile diagnostic errors could be reported similarly to the mix compile ones. I believe the logic needed to decide if the location of the file where the error is being reported belongs to deps or to the developer's current source code could easily be handled by either elixir-ls or the editor.

The fact that the task current eagerly exits is what makes removes all flexibility from being able to decide what to do with the errors at a later stage.

[José Valim]

Gabriel, sorry my question was not clear enough. What is the benefit for users in this case? Why should an IDE should warnings from their deps in a way that capturing stderr is not enough?

To view this discussion on the web visit https://groups.google.com/d/msgid/elixir-lang-core/cac47a1c-c153-4cec-9dbb-bc43a6bb2192n%40googlegroups.com.

[Guilherme Duarte]

No worries. Thanks for detailing it better.

The benefit for the users would be the possibility to know where exactly the compilation errors are coming from. This would be especially useful when users use path dependencies. 
Perhaps it could be even be implemented as a path dependency-only feature. Although, I do think that --return-errors should never exit, but instead return a list of errors, as the documentation suggests.

What do you think?

[José Valim]

I think this would be welcome but would we need special flags to control the deps? And again, there is a huge disclaimer that this won't work for rebar3 dependencies and similar. It may also be not very straightforward to implement.

To view this discussion on the web visit https://groups.google.com/d/msgid/elixir-lang-core/92d78373-6c4c-468c-a30b-869d1b1825fcn%40googlegroups.com.

[Guilherme Duarte]

Cool, I'll see if I can jot a proposal on a PR with a possible implementation.