Include recent logs by default

[devinrhode2]

I think we should definitely include recent logs in error reports. Not only is a stack trace really useful, but logging state variables and including those is fantastic too.

I'll have some code for this ready soon, but what do you guys think?

We could include the 10 most recent logs by default, but you can set that number to anything you want, similar to how TraceKit has configurable number of lines of context (which is undocumented)

I can also include the function name that called log

[devinrhode2]

On inclusion of the function name, basically this code:

function foo() {
  log('bar');
}

Would result in this being pushed to the log.history array:

['bar', 'caller:foo']

I think having an explicit log function is better than intercepting console.log because it's an explicit way of saying 'log this to the console AND in error reports' (but I do have code for intercepting console.log if we want)

[eriwen]

We should probably use the convention many other logging frameworks do with an API like so:

log.debug('..');
log.info('..');
log.warn('..');
log.error('..');

I think this is a good idea, but not a core part of the library. This should be split out into a plugin.

[devinrhode2]

Yeah.. if we're doing log.info etc maybe it's better to just intercept all the console api's..

Anyway, here's my window.log implementation, with inspiration from Paul Irish's version, https://gist.github.com/4705947

I could actually figure out something where you do var console = log or window.console = log and instead of our log.info, log.debug, log.warn and log.error you just use console.apis instead. We could also have a console.

The data structure of log.history that I'm thinking:

[
  ['info' , 'info arg 1'  , 'more info' , 'caller:unrulyFunction'],
  ['debug', 'another call', 'debug arg2', 'caller:unrulyFunction']
]

Also, I figured in leu of a function name, I'll just include the first X chars of the function's toString value

I'm envisioning a real end-to-end solution, I'm envisioning you drop in the library and there's a free dashboard that's activated, etc

I think the whole library could have free cross domain requests by doing new Image().src = 'up-to-a-2000-character-request';

Also considering that you just can't get stack traces in IE, reporting recent logs basically makes up for that.

[devinrhode2]

I've been working hard on this window.log code, and am not sure how else to improve it: https://gist.github.com/devinrhode2/4705947

I would love feedback on it; docs are inline at the top. Please go ahead and edit it up

[devinrhode2]

Ok re-did the api again and moved it to it's own repo: https://github.com/devinrhode2/historicalConsole.js

If we included it by default, we could have an api like:

Shield(function(){
});

And then to include console history you do this:

Shield(function(console){
});

When you include the console parameter, all the console methods in this scope log to console.history, in addition to performing their native capabilities

A nice api to keep the 2 separate but seamlessly integrated would be to override console.history.push with a callback

Would love some feedback

[victor-homyakov]

Is history somehow limited in size?

[devinrhode2]

no

[victor-homyakov]

Will this cause memory problems on long-running pages?

[devinrhode2]

Considering the use case is to bundle recent logs with error reports, we should impose a size limit on the array.

I think the way to do this is to define a custom console.history.push method

[devinrhode2]

Code changes: devinrhode2/historicalConsole.js@3ade22d
Doc changes: devinrhode2/historicalConsole.js@973a083

[devinrhode2]

@occ @eriwen @mattrobenolt how do you guys feel about this api:

Shield(function(console) {
  //error reports include a history of console.* methods that were called
  //(perhaps the 20 most recent logs leading up to the error)
});

Shield(function(){
  //no error reports, because `console` hasn't been overridden
});

Overriding console is strictly limited to the Shield callback, but global console logging can be achieved with: window.console = console; in the callback.

Between the 5 of us we can vote on whether or not this should be included by default and move onward to figuring out a module system