Review: Usage of `console.warn` vs `console.log`

Is your request related to a specific problem you’re having?

Recently (during release of 9.18.4) I learned that warn is just an alias of error - and in the Node.js runtime writes to STDERR. This seems very dumb and very surprising (not just to me but to others I’ve spoken with). Based on this we need to carefully review our use of log, warn, and error to decide if some of our warns should become logs instead or if perhaps we should have different behavior between Node.js and browser regarding logging.

First our use of console.error, which might be ok

1. registerLanguage

console.error("Language definition for '{}' could not be registered.".replace("{}", languageName));
if (!SAFE_MODE) { throw error; } else { console.error(error); }

In the browser this will allow execution to continue (since the only thing that changes to my understanding is the log color) but on the server this will output an error to STDERR but NOT throw. Does that discrepancy seem ok? AFAIK no one has had any issues with this.

1. highlight logs error if you specifically request a language that’s unknown

    const language = getLanguage(languageName);
    if (!language) {
      console.error(LANGUAGE_NOT_FOUND.replace("{}", languageName));
      throw new Error('Unknown language: "' + languageName + '"');
    }

This seems right to me. It’s a hard error on both the client and server - not only logs but throws. Presumably the user has asked for the highlighted language by name - so it should be on them if they have provided the wrong name. There is really no SAFE_MODE kick in here - since what could it do - since we have no idea what language to use for highlighting…

console.warn

Meanwhile we warn on 8 occasions. 6 of those are deprecation notices, which I believe we should perhaps now change to just log… should we be writing small feature deprecation notices to STDERR? I don’t think so. Although many of these deprecations mostly only affect the client or we’d probably had a few annooyed people after upgrading to 10.5.

The other two are in blockLanguage, in the browser:

      if (!language) {
        console.warn(LANGUAGE_NOT_FOUND.replace("{}", match[1]));
        console.warn("Falling back to no-highlight mode for this block.", block);
      }

This is only browser-side so it shouldn’t affect Node, but I wonder if we should just move all our browser warns back to log and just avoid log completely to avoid any confusing in the future? I would probably add log.warn for these which would add a "WARN: " prefix… and also give us a single place to alter this behavior in the future if we decided to say start treating warnings differently between say browser and Node based on auto-detect.

[joshgoebel]

I added more notes. My recommendation:

• Change console.warn everywhere to log.warn (log being a custom namespace) and default that to an alias to console.log with the added “WARN:” prefix. (to allow future flexibility)

I like this because I still think of these as warnings, even though we may not want them triggering error conditions by writing to STDERR on the server.

I guess log.log might be funny but then i’d probably just go with logger or some such convention.

[joshgoebel]

Thoughts on adding a log.deprecated(version: string, message: string) also?

Nice.