Logging Woes

** Logging is problematic. **

I've found the aframe logs to always be an issue.

1. the aframe 'captured' logs, warning, errors, are presented without the stack trace, which makes debugging unnecessarily harder. I'm also not aware of how to turn these off--if that doesn't exist, then I also don't see any benefit, but I can't say I've looked explicitly for that feature. Even if so, though, I'd definitely ask that warning logs have the stack trace perserved...

2. THREE logs...
   I've slowly come to realize that it's kind of a thorny issue to solve, that THREE constantly updates their API, and that they're noisy. It looks like they don't implement a debug on/off function. The move from AFRAME 1.0.4 to 1.1.0 created a gigantic mess of noisy logs about a render error that I'm aware of and don't care about that I'm stuck with scrolling past every time I open my logs on my app. That's just one of many noisy THREE problems.

I assume each A-Frame release picks a target THREE and includes it internally, since that's how THREE recommends development should be done on it. If so, could we possibly do our own build of THREE with all console.log/warn/error converted to a debug method with a flag that we can turn on/off?

I ask this now because I finally have a situation that may require me to just do that by hand. Including the superhands component , with the required aframe-physics-system component, with A-Frame 1.1.0, in a basic configuration in my app, is causing a THREE warning about a renamed function on every tick that is causing my entire computer to crash.

At first I filed an issue with superhands, then I realized it was an issue with aframe-physics-system. Then I realized--what can they do about it? Make sure their code always targets only the latest A-Frame build of THREE? And keep up with that?

Isn't that a bit much? I mean, sure, if it becomes breaking, yes, they'll have to update, but just because the logging for a minor version difference?

For developer convenience on many fronts, it would be really nice if we had a way to turn THREE logs off. Frankly, I'm surprised this doesn't seem to be a feature in THREE itself.

two hours later

So after writing that line, I decided to confirm a little more deeply. I didn't realize that this was a huge issue that had been argued about over the last 6+ years over there, and that has also been weighed in on by dmarcos, and that other issues have also been opened here on this issue.

I would ask that the A-Frame developers reconsider, as this literally makes work more difficult, not less. I commented on THREE as well, though I obviously doubt that will do anything, and I know support has been expressed by @dmarcos for whatever they choose to do on this issue in the past, but... as I mentioned, I can't open my console now, because THREE logs cause it to crash until I go hack my console. That situation is absurd. No other mature JS library creates this problem, as none decide they are better able to decide what should go in your logs than the developer using the library is.

I agree this should be handled by THREE, of course, but in the meantime...

Anyways, my $0.02. As always, thanks for A-Frame, it's still a project I have great fondness and respect for.

No files, tests, or entry points are named. Start by reviewing A-Frame’s logging integration and the bundled THREE logging behavior, then read the linked discussion history to understand the existing constraints. Done would require a clearly agreed approach for controlling noisy THREE logs while preserving useful warning and error context.