File/Line numbers?

[sam-lex]

Currently the line numbers are lost: showing as index.js which points to where the console.log is being called

This picture shows as vendor.bundle.js because I had --sourcemap=false on.

I did managed to get it to show the "correct" file/line like so:

But with a major downside, and that is having to make the call with extra ().

// before
this.logger.trace('Hi there');
// after
this.logger.trace('Hi there')();
// changes
this.logger.trace('Hi there') // returns a "formatted console.log function"
// so executing right after would result into showing the right file/line number

To avoid breaking the api, we could set a flag to make it either log directly or return a function.
I can't think of a "pretty" way of doing this though. Any thoughts?

[sam-lex]

have a look, I'll make a pull request if this is ok:
sam-lex@0f1a832

Changes:

• added logImmediately option, defaults to true
• _log now returns a formatted console log function

Usage:

// Same as before, no changes
this.logger.trace('Hi there'); // Hi there                   index.js ...

// or .. set 'logImmediately' to false:
LoggerModule.forRoot({
  serverLogLevel: NgxLoggerLevel.TRACE,
  level: NgxLoggerLevel.TRACE,
  logImmediately: false
}),
// and add '()' when using
this.logger.trace('Hi there')(); // Hi there                app.component.ts ...
// if 'logImmediately' is not defined or set to true.
// It will log twice. Once inside the logger function, and once on the 'caller' side.

_logIE(..) part is not implemented yet. For now, it just returns an empty function () => {} at the end.

Not sure if it's worth the trouble though, adding '()' can be quite annoying .. and ugly.

[avatsaev]

so, was this merged?

[sam-lex]

nope, not yet ...
I've been using this "new way" of adding extra (). Works ok, but many times I log and forget the extra (), so I go and test my app and keep thinking why my log doesn't get called, then I keep looking at different places where I might have messed up, until I realized I forgot the ().

So instead of really helping, it could hinder your development (sometimes).

Tried looking at how other loggers do it, they don't (without some sort of performance implications - like using the Error().stack and parsing it somehow).

[avatsaev]

yep I just tried by packaging your fork, it works but it feels hacky with the extra ().

Without showing the file and line number it's pretty difficult to debug.

[dbfannin]

@sam-lex, I'm not sure I like returning a function for this non logImmediately function. However, I can see the benefit in being able to have the line number from where the logger was called.

Here are my thoughts:

1. Most users are probably writing their log messages so that they are unique and can be easily found using the logged message alone. This is a pretty standard best practice for logging.

2. Mixing the intent of the logging methods doesn't follow the SOLID practices.

So how do we extend the logger with these things in mind:

1. We can't penalize the majority of the users
2. We need to be explicit in how the logger works without obscurity (when possible)
3. We should do our best to be "SOLID".

One idea would be to have a function that builds and returns the arguments that are passed to console.log. You could use the logger to build out the arguments, but call console.log in your own file:

const args = this.logger.getArgs(NgxLoggerLevel.ERROR, 'My error message', {more: 'stuff here'});
console.log(...args)

getArgs would return

[
    `%c2017-09-19T13:00:56Z [Error] %cMy error message`, 
    `color:red`, 
    `color:black`, 
    {more: 'stuff here'}
]

I realize this would be more code to type than adding () at the end of the logger call, but this new method could be leveraged by the existing logging methods and it would have a single purpose. Also, when using it this way, you wouldn't accidentally forget to add the (), but instead it would be very clear what arguments the method needs to complete its task.

Your thoughts?

[sam-lex]

Yeah, adding () is really not ideal. Creating a getArgs function to later call it yourself with console.log does make it clear and easy to understand what's happening, but I think it's way too much code to make it worth.

Since my javascript knowledge is very limited, I'll have to research more before I can suggest another solution.

One idea that I got, but have no clue how to do it, or if it's even possible:

Override the console.log method. (yes this sounds terrible, but hold on..)
Just to make it call the _logOnServer method.
then, call the original console.log.

Reason, it's possible to return a "formatted" console.log.
With slight modifications we could change:
debug(...args) to debug = (formatted console log function)
so we could use it like so:
this.logger.debug('hi there');

which is perfect except that it won't log to the server.

So if it's possible to somehow chain the _logOnServer to console.log automatically, or override it at instance level so that it won't affect the normal console, then we can get this done beautifully.

[leo6104]

I found some stack overflow documents (related to stack trace / caller function tracking)

https://stackoverflow.com/questions/280389/how-do-you-find-out-the-caller-function-in-javascript

We can trace caller function by arguments.callee.caller.caller in private _logIE function or private _log function

https://developer.mozilla.org/ko/docs/Web/JavaScript/Reference/Global_Objects/Function/caller

There is some method to find out the implement file name & position from function reference.

https://stackoverflow.com/questions/1340872/how-to-get-javascript-caller-function-line-number-how-to-get-javascript-caller
Cross browser support stack trace -> https://github.com/stacktracejs/stacktrace.js

To support this method properly with all browser, it might be require some additional dependency.
If we accept additional dependency, this feature can be supported with above method. :)

[dbfannin]

@sam-lex, I don't think we should go the route of overriding console.log. It would never be a good idea to do something like this. Since console is shared globally, it would not just make the change for your code, but also for every other module that you've imported. It could have some pretty gnarly side effects.

@leo6104, It appears that arguments.callee.caller is deprecated.
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Functions/arguments/callee

[leo6104]

@dbfannin 😭 Okay, i try to find another way. Thank you for giving updated information. (Korean references are not up-to-date translations.)

[Tom4U]

Any news on this? Seems to be some kind of common problem in JS as I could find out through Google search.

[sam-lex]

not on my side, I've been using my own work-around version, but is not really useful to me anymore, it's taking a long time to build my angular project. angular/angular-cli#5775 (comment)

so with ng serve --sourcemap=false, is just shows main.bundle.js: ...line number

[abielikesu]

Hi Guys,

@dbfannin your idea about the args is great, and it actually has many more use cases. It resembles my favourite GoLang logging library: https://github.com/Sirupsen/logrus

The syntax I normally use goes like this:
log.WithFields(log.Fields{ "module": "Animals", "animal": "walrus", }).Info("A walrus appears")