*
On Dec 26, 2024, at 6:20 PM, Simon McConnell
<simonmcconn...@gmail.com> wrote:
Brandon, you can do things about some of the warnings, e.g. go to the
repo and submit at PR.
Consider a monorepo where path dependencies are used. I don't believe
that hiding each dependency's warnings by default would be ideal.
*
Hey, I get the mantra. I've been around long enough in the OSS word to
have contributed to apache before it was apache, and was a freebsd
developer.
But let's be realistic, what you've described just isn't how it works.
For me to go figure out why a thing is happening in a new code base
requires me to first get my head into that code base—possibly hour(s) or
more depending on how good the other author(s) were writing it. I just
don't have time to go figure out everybody's code.
What I'd like is a more code-automation friendly output (enabled with
cmd line option). JSON stream maybe (line-delimited JSON).
I have a rule that there's zero warnings in my team's codebase, but to
enforce that with the way it works now is a royal nightmare to script,
and still exclude the deps.
So instead, we have a wrapper around all of the output to detect
warnings as part of our CI process, and separately which wraps and
cleans up the output of coveralls. I prefer very tight and clean output
that tells the developer exactly what they need to know (and only
that—coveralls is too great an infodump).
The problem here is that one has to consider the purpose of the output
during compile, and it's not just a simple single-purpose thing:
1. progress?
2. notification report of problems in your code (what 99.999% of all
the devs care about)
3. notification report of all problems everywhere
4. notification report of problems in deps?
The challenge here is that the output is trying to be all of these at
once, and you get a less than optimal output for each when you mash them
together.
To really get wild with it, what about an option for each? :D
-Brandon Gillespie
--
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-core+unsubscr...@googlegroups.com.
To view this discussion visit
https://groups.google.com/d/msgid/elixir-lang-core/89e12137-e435-4fd8-b960-efe67e336fd4%40cold.org.
