@firebase/logger #473

jshcrowthe · 2018-01-29T23:31:24Z

This PR has two parts, 1) the @firebase/logger module and 2) the integrations with @firebase/database and @firebase/firestore.

`@firebase/logger`

This module exports a class called Logger which supports the following 5 log methods:

debug
log
info
warn
error

Log Handlers

Each instance of logger, will, by default, log to the corresponding console method (i.e. console.debug, console.log, console.info, console.warn, console.error), however the logHandling itself is customizable by passing a new logHandler function to a Logger instance.

Each log handler has the following signature:

export type LogHandler = (
  logType: LogLevel,
  currentLogLevel: LogLevel,
  ...args: any[]
) => void;

The handler is passed:

the intended log type (i.e. did I call the log method, or the error method of my Logger instance?)
the current log level (i.e. LogLevel.VERBOSE, or LogLevel.ERROR, etc. This will be discussed in more detail below)
An array of arguments to actually log

The default handler, respects the passed log level, and if it is a valid log, passes it on to the appropriate console stream.

You can define other handlers on an as needed basis.

Log Levels

We support 5 "active" levels and a "silent" mode for our logs. The full log set we support will be:

export enum LogLevel {
  DEBUG,
  VERBOSE,
  INFO,
  WARN,
  ERROR,
  SILENT
}

All of the log levels besides LogLevel.SILENT map to a console value and should be used instead of the console functions (to allow us to centralize logging for the SDK). LogLevel.SILENT, by default, disables the logs (however each LogHandler can decide what it wants to do with this level).

Integrations with other SDKs

`@firebase/database`

See f5ad492 for detailed diff

I replaced the logging utilities found in https://github.com/firebase/firebase-js-sdk/blob/logger/packages/database/src/core/util/util.ts, these are used throughout the SDK which quickly propagated the change to the rest of the database SDK. We have not yet exposed the log levels here.

All of the enableLogging functionality remained unchanged.

`@firebase/firestore`

See 4e59a63 for detailed diff

I replaced the logging utilities found in https://github.com/firebase/firebase-js-sdk/blob/logger/packages/firestore/src/util/log.ts. Firestore uses a subset of the log types we intend to support and as such a small map was required.

mikelehen

Generally looks good, but got some feedback / suggestions for ya. :-)

mikelehen · 2018-01-31T22:03:17Z

packages/database/src/core/PersistentConnection.ts

-      if ('msg' in body && typeof console !== 'undefined') {
-        console.log('FIREBASE: ' + body['msg'].replace('\n', '\nFIREBASE: '));
+      if ('msg' in body) {
+        log('FIREBASE: ' + body['msg'].replace('\n', '\nFIREBASE: '));


I believe this was explicitly meant to be logged without turning on logging. Essentially you can use a special auth token and the backend will send back debug messages that get automatically logged to the console.

mikelehen · 2018-01-31T22:04:46Z

packages/database/src/core/Repo.ts

@@ -653,7 +653,7 @@ export class Repo {
    forEach(stats, (stat: string, value: any) => {
      // pad stat names to be the same length (plus 2 extra spaces).
      for (let i = stat.length; i < longestName + 2; i++) stat += ' ';
-      console.log(stat + value);
+      log(stat + value);


Again, this is actually meant to be logged to the console, without enabling any logging settings.

mikelehen · 2018-01-31T22:13:51Z

packages/firestore/src/util/log.ts

@@ -19,37 +19,42 @@
 import { SDK_VERSION } from '../core/version';
 import { AnyJs } from './misc';
 import { PlatformSupport } from '../platform/platform';
+import { Logger, LogLevel as _LogLevel } from '@firebase/logger';
+
+const client = new Logger();


client => firebaseLogger? (or at least logClient or similar)

logClient is the name used in packages/database/src/core/util/util.ts.

mikelehen · 2018-01-31T22:14:25Z

packages/firestore/src/util/log.ts

@@ -19,37 +19,42 @@
 import { SDK_VERSION } from '../core/version';
 import { AnyJs } from './misc';
 import { PlatformSupport } from '../platform/platform';
+import { Logger, LogLevel as _LogLevel } from '@firebase/logger';


_LogLevel => FirebaseLogLevel ? (maybe Logger => FirebaseLogger too for symmetry)

mikelehen · 2018-01-31T22:21:20Z

packages/firestore/src/util/log.ts

 }
 export function setLogLevel(newLevel: LogLevel): void {
-  logLevel = newLevel;
+  client.logLevel = newLevel;


Shouldn't this do the inverse LogLevel => _LogLevel mapping as getLogLevel()?

Technically we don't have to because the 3 log types that Firestore supports are supported by the Logger package itself. This just works.

Ahh, and TypeScript is validating that I guess (if you added a different entry to Firestore's LogLevel, typescript would complain?).

If so, cool though I'd still probably add a comment to that effect:

// Since Firestore's LogLevel enum is a pure subset of Firebase's LogLevel, we can return it directly.

mikelehen · 2018-01-31T22:36:59Z

packages/logger/src/logger.ts

+/**
+ * A function to set the default log level externally
+ */
+export function setDefaultLogLevel(val: LogLevel) {


What is this function for? Setting the default seems nonintuitive (the default is what you get if you don't set the log level).

It was originally to help with some testing and I thought it might be nice to allow people to set the default and have it persist. Per feedback here, I've removed it.

mikelehen · 2018-01-31T22:37:17Z

packages/logger/src/logger.ts

+ */
+export function setDefaultLogLevel(val: LogLevel) {
+  if (!(val in LogLevel)) {
+    throw new TypeError('Attempted to Invalid value assigned to `logLevel`');


grammar malfunction (here and below)

I need to get like a grammar checker for my code haha.

Also would be nice to include the value here.

mikelehen · 2018-01-31T22:39:32Z

packages/logger/src/logger.ts

+      console.error(...args);
+      break;
+    default:
+      console.debug(...args);


Per https://developer.mozilla.org/en-US/docs/Web/API/Console: Starting with Chromium 58 this method only appears in Chromium browser consoles when level "Verbose" is selected.

Which means we don't want to do it (developers shouldn't have to opt into logs twice to get them).

I'll refactor this to a console.log

mikelehen · 2018-01-31T22:42:50Z

packages/logger/src/logger.ts

+    case LogLevel.SILENT:
+      return;
+    case LogLevel.VERBOSE:
+      console.log(...args);


The format in your proposal was:

[<timestamp>] <name>@<version>: <message>

Are we not doing that?

Great catch on this, I forgot it entirely. I'll rev this appropriately

mikelehen · 2018-01-31T22:49:47Z

packages/logger/src/logger.ts

+  if (!(val in LogLevel)) {
+    throw new TypeError('Attempted to Invalid value assigned to `logLevel`');
+  }
+  defaultLogLevel = val;


Hrm... So if you call setDefaultLogLevel(), which I assume will be the public API we eventually expose to users, shouldn't we notify all of the existing instances? As a user I should be able to enable / disable logging at will.

I'm fuzzy on how the global and per-component log levels are meant to interact. E.g. what happens if I set the default one, then set a per-component one, then set the default one again?

Honestly I would just simplify and only have the default / global log level for now. But if you keep both, please make sure they interact in a sane way (taking into consideration how you expect to expose the API to the end user eventually).

I would go even further and suggest that we only need to set the default log level for the Firebase logger. If a user specifies their own logger, they can strip out log messages as they deem necessary.

I've tried to make it so that each log client can set their own log levels (e.g. Database and Firestore, currently, can't rely on a single log level as they are handled separately). Though there are other ways you could solve this, I've opted to just keep the LogLevel, local to the Logger instance.

I've removed the global default thing, so that is gone.

There is still a top level "set-all" type of functionality. This will allow us to do global level sets across all Logger instances which we will need going forward.

schmidt-sebastian · 2018-02-01T18:30:01Z

packages/firestore/src/util/log.ts

@@ -19,37 +19,42 @@
 import { SDK_VERSION } from '../core/version';
 import { AnyJs } from './misc';
 import { PlatformSupport } from '../platform/platform';
+import { Logger, LogLevel as _LogLevel } from '@firebase/logger';
+
+const client = new Logger();


logClient is the name used in packages/database/src/core/util/util.ts.

schmidt-sebastian · 2018-02-01T18:32:24Z

packages/database/src/core/util/util.ts

@@ -179,14 +167,8 @@ export const fatal = function(...var_args: string[]) {
 * @param {...*} var_args


This comment is for the hidden block just above (line 173): I feel that we should also log 'fatal' messages to the user-specified log functions.

schmidt-sebastian · 2018-02-01T18:39:07Z

packages/logger/src/logger.ts

+ */
+export function setDefaultLogLevel(val: LogLevel) {
+  if (!(val in LogLevel)) {
+    throw new TypeError('Attempted to Invalid value assigned to `logLevel`');


Also would be nice to include the value here.

schmidt-sebastian · 2018-02-01T18:40:13Z

packages/logger/src/logger.ts

+ */
+export type LogHandler = (
+  logType: LogLevel,
+  currentLogLevel: LogLevel,


Can you make sure these names match?

I've refactored this a bit PTAL

schmidt-sebastian · 2018-02-01T18:41:12Z

packages/logger/src/logger.ts

+  if (!(val in LogLevel)) {
+    throw new TypeError('Attempted to Invalid value assigned to `logLevel`');
+  }
+  defaultLogLevel = val;


I would go even further and suggest that we only need to set the default log level for the Firebase logger. If a user specifies their own logger, they can strip out log messages as they deem necessary.

schmidt-sebastian · 2018-02-01T18:42:35Z

packages/logger/src/logger.ts

+   * centrally set, each logger can be set individually if it desires.
+   */
+  private _logLevel = defaultLogLevel;
+  get logLevel() {


Please add typings here and below.

schmidt-sebastian · 2018-02-01T18:42:49Z

packages/logger/src/logger.ts

+  }
+  set logLevel(val) {
+    if (!(val in LogLevel)) {
+      throw new TypeError('Attempted to Invalid value assigned to `logLevel`');


Make sure this message is also updated.

schmidt-sebastian · 2018-02-01T18:44:14Z

packages/logger/test/logger.test.ts

+  };
+  /**
+   * Before each test, instantiate a new instance of Logger and set the log
+   * level so that all


Please finish your thought :)

schmidt-sebastian · 2018-02-01T18:44:29Z

packages/logger/src/logger.ts

+  /**
+   * The log handler for the current logger instance. This can be set to any
+   * function value, though this should not be needed the vast majority of the
+   * time


I would remove the second sentence.

mikelehen

Some more feedback. I'm still not thrilled with the set of LogLevels we're landing on (and I'm confused about the intent of LOG / DEBUG since you seem to be (intentionally?) merging them into console.log calls). It probably makes sense to come to consensus on the set of LogLevels and their behavior before doing another full round of code review. Feel free to comment here or ping me directly or whatever.

mikelehen · 2018-02-22T02:00:11Z

packages/firestore/src/util/log.ts

-    console.log(`Firestore (${SDK_VERSION}) ${time} [${tag}]: ${msg}`, ...args);
+    logClient.log(
+      `Firestore (${SDK_VERSION}) ${time} [${tag}]: ${msg}`,
+      ...args


Are we logging time twice now?

Good point, I have pulled this from these logs.

mikelehen · 2018-02-22T17:33:20Z

packages/firestore/src/util/log.ts

-  logLevel = newLevel;
+  /**
+   * Since Firestore's LogLevel enum is a pure subset of Firebase's LogLevel, we
+   * can return it directly.


Looking at this again, I'm 90% sure this doesn't actually work. At runtime, newLevel is just going to be a number (e.g. 1, corresponding to ERROR) and it's going to get assigned to logClient.logLevel as a number (e.g. 1, now corresponding to LOG). I really don't know why TypeScript even compiles this. :-/

I've refactored this to do a manual set. PTAL.

mikelehen · 2018-02-22T17:39:39Z

packages/firestore/src/util/log.ts

 }

 export function debug(tag: string, msg: string, ...obj: AnyJs[]): void {
-  if (logLevel <= LogLevel.DEBUG) {
+  if (logClient.logLevel <= FirebaseLogLevel.DEBUG) {


Are you intentionally comparing to DEBUG and then using .log() below [as opposed to .debug]? I'm guessing this should be .LOG here, but then we also need to change the setLogLevel() code above to map Firestore's DEBUG LogLevel to Firebase's LOG LogLevel...

Great catch here, refactored the logging call to logClient.debug

mikelehen · 2018-02-22T17:47:14Z

packages/logger/README.md

+instance:
+
+- `debug`: Internal logs; use this to allow developers to send us their debug
+  logs for us to be able to diagnose an issue.


So console.debug() logs are disabled by default in Chrome Dev Tools (the developer needs to explicitly change the log filter to "verbose.") This means that to get these logs from a developer we would need to tell them to set the LogLevel to DEBUG and change the filter in chrome dev tools. We don't want to make them do two steps (and in general there's no reason to have two gates for enabling / disabling our logs).

So I think we should avoid using console.debug() entirely. It'll just cause confusion. This means we need to either drop LogLevel.DEBUG or make it use console.log() [in which case we should drop LogLevel.LOG]. My preference is for dropping LogLevel.LOG.

I've left a comment in logger.ts to explain this and I am now intentionally routing debug logs to console.log.

I feel like there is still a valid distinction to be made between LogLevel.INFO and LogLevel.LOG.

Some strawmen for examples:

LogLevel.INFO: If a user doesn't initialize an app with all of the config required to init all the services (think, if we add a new field to that config), this would be a good INFO candidate. It's not immediately breaking, and a user has an action item they can take to alleviate the issue.

LogLevel.LOG: If a user is trying to use some feature that has suffers from unsolvable performance issues in Hybrid environments, we may Log a message notifying the user that there is some known slowness.

If there's an action item for the user, wouldn't we want the log on by default? INFO logs are off by default, so that would not be appropriate.

But my bigger problem is that "LOG" is meaningless since these are all logs and I've never come across another logging system that has "LOG" as its own log level so nobody will know what this means or where it fits in the overall ordering. Even other JavaScript loggers (where log as a loglevel might almost make sense because of the console.log legacy) don't have it...

winston [10k stars] - error, warn, info, verbose, debug
bunyan [5k stars] - fatal, error, warn, info, debug, trace
loglevel [1k stars] - error, warn, info, debug, trace

So I appreciate that you've made up your own level and have strawmen examples to back it up, but I think it would be better to stick with well-known ones.

I think in practice:

90% of customers will stick with the default (warn and error) all the time.

10% of customers may enable debug logging because support asked them to or they found a StackOverflow / forum post that mentions it.

0% of customers will care to distinguish between info/log/debug.

Only Firestore and RTDB use these logs and they only have error, warn, and debug. So there's currently no distinction to make anyway.

All that said, I don't really care. I think we should avoid LOG. If you think we need 5 log levels instead of 4 or 3, then please pick from the existing set of log levels that other systems use (notice, verbose, trace, etc.) for your 5th. Keep in mind we could always add more log levels later if we need them.

mikelehen · 2018-02-22T17:50:34Z

packages/logger/README.md

+
+- `debug`: Internal logs; use this to allow developers to send us their debug
+  logs for us to be able to diagnose an issue.
+- `log`: Use to inform your user about things they may need to know.


As mentioned, I'd like to drop "log" but if we keep it, can you make this description clearer? Is "your user" the Firebase end developer? And what does "may need to know" mean? Perhaps an example would help.

mikelehen · 2018-02-22T18:30:19Z

packages/logger/src/logger.ts

+    case LogLevel.ERROR:
+      console.error(`[${now}]  ${instance.name}:`, ...args);
+      break;
+    default:


You left out DEBUG

Rather than default to console.log(), I'd throw an exception. That way you'll notice if you leave out a log level. If for some reason you were intentionally handling DEBUG via the default: case, then a comment is warranted to explain your intent.

mikelehen · 2018-02-22T18:31:51Z

packages/logger/src/logger.ts

+}
+
+/**
+ * A container for the default log level


Should this just be "The Default Log Level" (I'm not sure what 'container' refers to)

mikelehen · 2018-02-22T18:35:53Z

packages/logger/test/logger.test.ts

+
+  function testLog(message, channel, shouldLog) {
+    /**
+     * `debug` logs also go through log channel


This suggests you are currently intentionally merging log and debug messages, but I didn't see this explained anywhere... Did I miss it?

I pulled the beforeEach. Things should be working as expected.

mikelehen · 2018-02-22T18:36:17Z

packages/logger/test/logger.test.ts

+  const message = 'Hello there!';
+  let client: Logger;
+  const spies = {
+    debugSpy: null,


mikelehen · 2018-02-22T18:37:52Z

packages/logger/test/logger.test.ts

+    testLog(message, 'error', true);
+  });
+
+  describe('Defaults', () => {


How is this test different than the above one other than it's using WARN instead of DEBUG as the log level? Perhaps it should omit the beforeEach() so that we actually get the default log level automatically? And then the describe should be something like "Defaults to LogLevel.WARN" ?

Refactor to also log fatal issues Refactor to not attempt to log if the level is invalid Adding docs and more feedback

mikelehen · 2018-02-27T23:34:20Z

packages/logger/src/logger.ts

@@ -40,7 +40,7 @@ export enum LogLevel {
 }

 /**
- * A container for the default log level
+ * The sefault log level


sefault => default

mikelehen · 2018-02-27T23:39:25Z

packages/logger/src/logger.ts

+     * are early returning here. To allow custom log handlers to handle this
+     * behavior differently, we are still going to pass through logging calls
+     * to their handlers when the log level is set to `SILENT`.
+     */


I still don't understand this. AFAICT, there's currently no way for logType to be SILENT since there's no Logger.silent(...) method and it would never make sense to have one. So I think we should not have a case for SILENT and it should fall through to default: and throw.

mikelehen · 2018-02-27T23:45:13Z

packages/logger/test/logger.test.ts

@@ -52,13 +51,14 @@ describe('@firebase/logger', () => {

  function testLog(message, channel, shouldLog) {
    /**
-     * `debug` logs also go through log channel
+     * Ensure that `debug` logs assert against the `console.log` function. The


"assert against" doesn't seem like the right wording here. Perhaps just "via"?

mikelehen · 2018-02-28T00:08:30Z

packages/logger/README.md

+instance:
+
+- `debug`: Internal logs; use this to allow developers to send us their debug
+  logs for us to be able to diagnose an issue.


If there's an action item for the user, wouldn't we want the log on by default? INFO logs are off by default, so that would not be appropriate.

But my bigger problem is that "LOG" is meaningless since these are all logs and I've never come across another logging system that has "LOG" as its own log level so nobody will know what this means or where it fits in the overall ordering. Even other JavaScript loggers (where log as a loglevel might almost make sense because of the console.log legacy) don't have it...

winston [10k stars] - error, warn, info, verbose, debug
bunyan [5k stars] - fatal, error, warn, info, debug, trace
loglevel [1k stars] - error, warn, info, debug, trace

So I appreciate that you've made up your own level and have strawmen examples to back it up, but I think it would be better to stick with well-known ones.

I think in practice:

90% of customers will stick with the default (warn and error) all the time.

10% of customers may enable debug logging because support asked them to or they found a StackOverflow / forum post that mentions it.

0% of customers will care to distinguish between info/log/debug.

Only Firestore and RTDB use these logs and they only have error, warn, and debug. So there's currently no distinction to make anyway.

All that said, I don't really care. I think we should avoid LOG. If you think we need 5 log levels instead of 4 or 3, then please pick from the existing set of log levels that other systems use (notice, verbose, trace, etc.) for your 5th. Keep in mind we could always add more log levels later if we need them.

mikelehen

One nit left, but otherwise LGTM.

mikelehen · 2018-02-28T01:39:43Z

packages/logger/src/logger.ts

+) => void;
+
+/**
+ * The default log handler will forward DEBUG, LOG, INFO, WARN, and ERROR


LOG => VERBOSE

schmidt-sebastian · 2018-02-28T18:12:26Z

packages/logger/README.md

+# @firebase/logger
+
+This package serves as the base of all logging in the JS SDK. Any logging that
+is intended to be for firebase end developers, should go through this module.


Remove comma and maybe reword as:

This package serves as the base of all logging in the JS SDK. Any logging that
is intended to be visible to Firebase end developers should go through this module.

schmidt-sebastian · 2018-02-28T18:14:28Z

packages/logger/README.md

+- `info`: Use if you have to inform the user about something that they need to
+  take a concrete action on. Once they take that action, the log should go away.
+- `warn`: Use when a product feature may stop functioning correctly; unexpected
+  scenario. Majority of user-facing logs.


It'd take out "Majority of user-facing logs.". This is likely only true when the user doesn't enable debug logging.

schmidt-sebastian · 2018-02-28T18:15:33Z

packages/logger/src/logger.ts

+ * DEBUG < VERBOSE < INFO < WARN < ERROR
+ *
+ * All of the log types above the current log level will be captured (i.e. if
+ * I set the log level to `INFO`, errors will still be logged, but `DEBUG` and


... "if YOU set the log level" ...

schmidt-sebastian · 2018-02-28T18:17:38Z

packages/logger/src/logger.ts

+   * The log level of the given Logger instance.
+   */
+  private _logLevel = defaultLogLevel;
+  get logLevel() {


Add return type.

Do we need to add add proper JSDoc to each of these methods? Or will you do this as part of firebase-types?

Done.

No, this module is only internally used for the time being. When we actually surface it to end developers, we'll take care of the typings.

schmidt-sebastian · 2018-02-28T18:17:46Z

packages/logger/src/logger.ts

+  get logLevel() {
+    return this._logLevel;
+  }
+  set logLevel(val) {


Add argument type.

schmidt-sebastian · 2018-02-28T18:17:54Z

packages/logger/src/logger.ts

+   * The log handler for the Logger instance.
+   */
+  private _logHandler: LogHandler = defaultLogHandler;
+  get logHandler() {


Add return type.

schmidt-sebastian · 2018-02-28T18:18:01Z

packages/logger/src/logger.ts

+  get logHandler() {
+    return this._logHandler;
+  }
+  set logHandler(val) {


Add argument type.

jshcrowthe requested review from mikelehen, schmidt-sebastian and wilhuff as code owners January 29, 2018 23:31

google-oss-bot added the needs-triage label Jan 29, 2018

jshcrowthe assigned mikelehen and schmidt-sebastian Jan 29, 2018

mikelehen suggested changes Jan 31, 2018

View reviewed changes

mikelehen removed their assignment Jan 31, 2018

schmidt-sebastian suggested changes Feb 1, 2018

View reviewed changes

jshcrowthe force-pushed the logger branch from f4d7190 to acc7872 Compare February 21, 2018 17:22

mikelehen suggested changes Feb 22, 2018

View reviewed changes

jshcrowthe added 19 commits February 26, 2018 09:07

Start work on @firebase/logger package

1eaa3fc

Refactor to remove debug dep

26a9fd0

[AUTOMATED]: Prettier Code Styling

07ff3ff

[AUTOMATED]: License Headers

0895b3d

Expose a LogHandler type

12118c0

Allow users to "silence" our logging

d3a4b6b

Adding some comments

e0e2ecb

Do @firebase/firestore integration

3d497db

Do @firebase/database integration

1add931

[AUTOMATED]: Prettier Code Styling

c7b8557

Refactor to propagate the default level if changed

51d519b

Add some basic tests

67e8f35

[AUTOMATED]: Prettier Code Styling

6128011

Feedback from @mikelehen and @schmidt-sebastian

f369890

Refactor to also log fatal issues Refactor to not attempt to log if the level is invalid Adding docs and more feedback

[AUTOMATED]: Prettier Code Styling

d90daab

Fixing an error message

36105b9

Updating yarn.lock

2ba4043

Address @mikelehen feedback

1d027ed

[AUTOMATED]: Prettier Code Styling

9c766dc

jshcrowthe force-pushed the logger branch from 1eb7f60 to 9c766dc Compare February 26, 2018 17:48

jshcrowthe added 2 commits February 26, 2018 09:49

Refactor logClient.log -> logClient.debug

53a96fe

Update deps

056610b

jshcrowthe assigned mikelehen Feb 26, 2018

mikelehen suggested changes Feb 28, 2018

View reviewed changes

mikelehen assigned jshcrowthe and unassigned mikelehen Feb 28, 2018

More @mikelehen feedback

4c01a1b

mikelehen approved these changes Feb 28, 2018

View reviewed changes

Fixing comment

3ec3d8a

schmidt-sebastian reviewed Feb 28, 2018

View reviewed changes

Feedback from @schmidt-sebastian

8b0c7e4

schmidt-sebastian approved these changes Feb 28, 2018

View reviewed changes

jshcrowthe merged commit 3d6289d into master Feb 28, 2018

jshcrowthe deleted the logger branch February 28, 2018 18:49

schmidt-sebastian mentioned this pull request Mar 13, 2018

Release 5.10.0 changed behavior of admin.database.enableLogging(true) firebase/firebase-admin-node#230

Closed

firebase locked and limited conversation to collaborators Oct 23, 2019

		@@ -179,14 +167,8 @@ export const fatal = function(...var_args: string[]) {
		* @param {...*} var_args

@firebase/logger #473

@firebase/logger #473

Uh oh!

Conversation

jshcrowthe commented Jan 29, 2018

@firebase/logger

Log Handlers

Log Levels

Integrations with other SDKs

@firebase/database

@firebase/firestore

Uh oh!

mikelehen left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

mikelehen Jan 31, 2018 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

`@firebase/logger`

`@firebase/database`

`@firebase/firestore`

mikelehen Jan 31, 2018 •

edited

Loading