-
Notifications
You must be signed in to change notification settings - Fork 97
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Making logging optional #54
base: master
Are you sure you want to change the base?
Conversation
- use `SentryService implements LoggerService` instead of `SentryService extends ConsoleLogger`; - add an ability to provide custom logger; - add an ability to disable logging entirely; - default logger is `ConsoleLogger` for backward compatibility;
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This looks good to me. I added a few comments just based on my perspective.
lib/sentry-core.module.ts
Outdated
@@ -37,7 +38,7 @@ export class SentryCoreModule { | |||
const provider: Provider = { | |||
inject: [SENTRY_MODULE_OPTIONS], | |||
provide: SENTRY_TOKEN, | |||
useFactory: (options: SentryModuleOptions) => new SentryService(options), | |||
useFactory: (options: SentryModuleOptions) => createSentryService(options), |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm a little confused on the injection of the options. It both seems to be injected here via the provider config, as well as in the constructor of the class via the inject-decorator. I would think just the inject-decorator would be infer, and this can be changed to just use useClass
instead of useFactory
and remove the inject
from here.
lib/createSentryService.ts
Outdated
import { SentryService } from './sentry.service'; | ||
import { ConsoleLogger } from '@nestjs/common'; | ||
|
||
export function createSentryService(options: SentryModuleOptions): SentryService { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I would move this to the constructor of SentryService
, so the defaulting is done there. That makes it easier in general to use this service I think, without having to rely on this factory.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actually, the users of that lib should not have an access to that low level implementation. All what other devs have to do - use @InjectSentry()
decorator in their projects without caring about what happenes under the hood.
But yeah, maybe for internal usage it makes sense to re-think the instantiation of SentryService.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Oh, I see, you wanted to move default logger instantiation to SentryService
's constructor! Yep, makes sense!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Fixed!
Sentry.captureMessage(message, Sentry.Severity.Debug); | ||
} catch (err) {} | ||
} | ||
|
||
verbose(message: string, context?: string) { | ||
message = `${this.app} ${message}`; | ||
try { | ||
super.verbose(message, context); | ||
if (this.opts && this.opts.logger && this.opts.logger.verbose) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is there any change verbose
is not defined on the logger? Isn't that part of the interface?
(same for debug above)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
As you can see the NestJS
's LoggerService
interface declares debug
and verbose
methods as optional. ConsoleLogger
implements all methods, but some custom loggers may omit these optional methods. This is just to be safe. Also, TS compiler suggested to check the availability of these methods.
export interface LoggerService {
/**
* Write a 'log' level log.
*/
log(message: any, ...optionalParams: any[]): any;
/**
* Write an 'error' level log.
*/
error(message: any, ...optionalParams: any[]): any;
/**
* Write a 'warn' level log.
*/
warn(message: any, ...optionalParams: any[]): any;
/**
* Write a 'debug' level log.
*/
debug?(message: any, ...optionalParams: any[]): any;
/**
* Write a 'verbose' level log.
*/
verbose?(message: any, ...optionalParams: any[]): any;
/**
* Set log levels.
* @param levels log levels
*/
setLogLevels?(levels: LogLevel[]): any;
}```
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ah, I missed that, makes sense!
- instantiate default `ConsoleLogger` in `SentryService` constructor
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nice. This looks good from my perspective.
Thanks again for doing it.
This currently has conflicts with the master branch... |
# Conflicts: # lib/__tests__/sentry.service.spec.ts
@ntegral merged! |
@holm @doctorrokter any chance of merging this? Would enable custom logger usage in combination with |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Please update the changes to resolve conflicts. Thanks
@doctorrokter I wanted to ping this one more time to see if it's feasible to get the merge conflicts resolved and merge this PR. I understand the OP was pretty responsive to feedback and yet the PR still didn't get merged, which can be frustrating. I'm hoping the repo maintainers can jump on this if the merge conflicts get resolved again. If the merge conflicts don't get addressed soon, I might re-fork these changes and resubmit a matching PR, because this change would really help my team deal with messy logs. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
SentryService implements LoggerService
instead ofSentryService extends ConsoleLogger
;ConsoleLogger
for backward compatibility;