@saw - some context here
We want to log all warnings with stack traces to (hopefully) make fixing those a bit easier. The only way we can get a stack trace in the browser is by creating and logging an error object.
Unfortunately, Chrome will always log errors objects in _red_ which means that all of our warning logs will be in red and look like errors. We've gotten feedback that warnings should not look like errors, so we changed the way we logged them.
The reason we went with group is strictly for visual purposes. It was the only reliable way we could get the warnings to display consistently between Firefox, Safari and Chrome. Additionally, they are collapsable much like an error is today. If we were to remove grouping, you'd be flooded with logs that are not clearly related. This will make debugging harder.
I'm all for removing console.group, but I would like to hear some suggestions on how we can fix this.
--- Edited to add
There are a couple things that the user can do here
1) Address the warning to make the console statements go away
2) If the warning is bad/useless/pointless, open an issue on us to remove the warning.
Aura also used console.group at some point (they may still do) and it made debugging impossible.
I feel like warnings with stack traces is a strange concept. Can't we give them a location reference without a stack trace?
@davidturissini I'm going to meet with @pmdartus next week to review the warning issues on your end.
Here's something I'd just like you to understand: when you add a new warning and we haven't fixed in in LGC you are creating a massive amount of noise for consuming teams, noise that they a) can't fix and b) can't filter out. This is a really bad experience for them! I suspect most of the warning people see come from LGC, not from their code, so basically these warnings are getting ignored. So I'd say the biggest problem right now is that warnings are added as a way of communicating, but they create noise and don't actually help anyone.
Maybe there is a way to fix LGC first to remove the warning before adding it for everyone else?
It would be great if we could make this land as part of 220.
@caridy @diervo Any concern about this?
@ekashida is this solved by #1193?
Yes, we can close this after we merge that PR. We will be removing the concept of warning logs and only actionable errors will remain.
Most helpful comment
@davidturissini I'm going to meet with @pmdartus next week to review the warning issues on your end.
Here's something I'd just like you to understand: when you add a new warning and we haven't fixed in in LGC you are creating a massive amount of noise for consuming teams, noise that they a) can't fix and b) can't filter out. This is a really bad experience for them! I suspect most of the warning people see come from LGC, not from their code, so basically these warnings are getting ignored. So I'd say the biggest problem right now is that warnings are added as a way of communicating, but they create noise and don't actually help anyone.
Maybe there is a way to fix LGC first to remove the warning before adding it for everyone else?