Repository: react
Issue: [DevTools Bug]: Warnings are too "loud", mislabeled and make console difficult to use
Labels: Type: Bug,Status: Unconfirmed

### Website or app

https://codesandbox.io/s/purple-moon-ts7xzs?file=/src/App.js

### Repro steps

It's not causing this in the codesandbox probably due to some flag missing, but locally in dev I've been getting the following when a stray prop is passed to a dom elem as an attribute (_NB this output is **truncated**, this isn't even the whole message_):

![Screen Shot 2022-10-07 at 10 39 51 AM](https://user-images.githubusercontent.com/317498/194645730-159ea8cf-7d7c-49f3-b5b3-7caaf5384b44.png)

## Problems with the current logging approach

1. **This floods the console and pushes all other messages out of screen, making debugging difficult.** This is the main issue.
2. The severity/"loudness" of this log message is out of proportion to the issue. This is a fairly minor issue as it typically does not actually break anything, yet this log drowns out actual issues that I need to see more urgently
3. This issue's importance is being misclassified & the wrong logging API used: `console.error` is being misused to log a warning. The purpose of different log levels is to allow the consumer (developer) to enable or disable logging of less important messages depending on their needs. Putting warnings in the "error" stream **takes this control away from developers**. When I am cleaning up upgrade issues, minor bugs etc. I will turn on warnings and see this, but when I'm trying to figure out why my GQL endpoints are erroring, I should be able to turn this off.

## Ask

My goal is to stop this effectively "breaking" the error console, i.e. making it unusable by flooding it with messages. Possible approaches:

1. move these warnings to console.warn, putting control back in the developer/consumer's hands
2. flag to disable the stack traces so messages aren't so enormous
3. use [console.groupCollapsed](https://developer.mozilla.org/en-US/docs/Web/API/console/groupCollapsed) to collapse these, so the stack is there but doesn't flood the console

## FAQ

### Why don't you just fix the errors? If you fix the errors, this isn't an issue. The solution is fix the errors.

I don't mean to brag, but I work on applications with *lots* of errors. I truly wish I could fix every single one, but I must pick my battles and this often means letting smaller issues slide in order to focus on bigger ones. Furthermore, when working on a shared application, it can be out of your power to fix all the errors. There are several reasonable reasons why someone would want to work on their application and ignore certain errors, at least temporarily.

In any event, "this is a valid error message so why should it be quieter" doesn't address the question of *proportionality*. Should a warning like this overtake the whole console? Should it use `window.alert`? Should it bail out and crash the whole application? It's clear that these approaches to alerting the developer/consumer to an issue are not proportional with the severity of the issue itself, and these more drastic approaches would be inappropriate, even if they "draw the developer/user's attention to the issue" as this clearly does.  **Not every issue is p0** which is why we have log levels, and in this context different log streams (info, warning, and error).

### How often does this bug happen?

Every time

### DevTools package (automated)

_No response_

### DevTools version (automated)

_No response_

### Error message (automated)

_No response_

### Error call stack (automated)

_No response_

### Error component stack (automated)

_No response_

### GitHub query string (automated)

_No response_