The Joys of Performant Debugging (Optional logs / warnings)

Description of the problem

Related to https://github.com/mrdoob/three.js/issues/7112, https://github.com/mrdoob/three.js/pull/5791, https://github.com/mrdoob/three.js/pull/19309 and a few more.

Is there any reason why we can’t suppress warnings from Three? Adding Three.warn / Three.log seems like a 5 minute PR with kinda 0 deprecation issues and 100% happiness increase of any CPU 🤔 …?

---

Short story long, I understand that deprecation warnings are there originally to help with debugging, and so are possibly any other warnings - but when Chrome tries to render (even hidden) 20k warnings right out of the door (it is a bit of a specific project case, as it generates a lot of materials on the go, but it still is a case.) the app and console freeze for 30 seconds.

Add hot reload plus Preserve Logs, it freezes until next calendar year 😂

While none of the things mentioned in warnings are mandatory or breaking at this moment (fixing required vector targets can wait until the version release, and materials won’t break on undefined in these specific cases.) the logs that the rest of the application spits out are important, very helpful for debugging, and also lost among 20k three.js warnings (hence this workaround isn’t really an option.)

Three.js version

• Latest

Browser

• Chrome

OS

• All of them

[mrdoob]

@donmccurdy I think that sounds good to me 👍 setCustomConsole maybe?

[donmccurdy]

Part of the problem with the A-Frame <-> three.js interaction here is that A-Frame is often used as a global script, and so aframe-physics-system can’t have a peer dependency on a particular version of three.js. If it did, it could reasonably pin to a known-compatible version.

three.js maintainers do spend a lot of time maintaining backwards compatibility, trying to minimize breaking changes, documenting any breaking changes in the release notes, and maintaining warnings to help users migrate from one version to the next. Anyone saying that three.js maintainers are not worried about backwards compatibility is incorrect. That said, (a) we do not have LTS releases like some larger projects, and (b) each monthly release is semantically equivalent, and could potentially contain breaking changes. The files under examples/{js,jsm} are less stable than the core library. If you’re using a CDN, the version of any dependency should always be pinned to a particular package version, or something will eventually break, and people don’t always do this.

---

If we don’t want to maintain a custom logging API, how about exporting a reference to the console variable and letting users swap it out? This would let them change where three.js logs go without needing to monkey-patch the global console object. For example:

// three.js
export let logger = console;
export const setDefaultLogger = (_console) => {
  logger = _console;
};

// DeprecatedLoader.js
import { logger } from 'three';
logger.warn('this loader is deprecated');

// app-with-no-logs.js
import { setDefaultLogger } from 'three';
setDefaultLogger({
  log: function() {},
  warn: function() {},
  error: function() {},
});