-
Notifications
You must be signed in to change notification settings - Fork 2
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
ref(logger): refactor logger impl to be separate from interface #784
Conversation
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.
[Tests]: as a quick sanity check to confirm that this is working could we push to to staging now then check tomorrow just see if visually looks ok?
|
||
// Constants | ||
// TODO: Check this env var as it is not in example | ||
const LOG_GROUP_NAME = `${process.env.AWS_BACKEND_EB_ENV_NAME}/nodejs.log` |
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.
Hey I dont understand this comment :(
this is in reference so some example in the documentation ah?
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 actually dk too - i tried asking @alexanderleegs but he didn't know too HAHAHAHA
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.
for context, this was in the old logger.js
and i copied this over because it seemed important
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 this comment is because me and Alex tried to find where this log exists, but we could never find it.
Might need to look again and if we conclude this is not being used anywhere, can remove
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 wasn't actually used until this PR - this was used in init
, which was never called till now. i decided to call it because it seemed to be setting transport defaults and cloudwatch log settings ._.
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.
npm run build
fails :(
hmm - we actually lack a build step in |
|
||
// Constants | ||
// TODO: Check this env var as it is not in example | ||
const LOG_GROUP_NAME = `${process.env.AWS_BACKEND_EB_ENV_NAME}/nodejs.log` |
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 this comment is because me and Alex tried to find where this log exists, but we could never find it.
Might need to look again and if we conclude this is not being used anywhere, can remove
export type Formatter = (message: string) => string | ||
|
||
export interface Logger { | ||
info: LogMethod |
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.
can we add debug & fatal as well?
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.
sure, but i do have a few questions:
- should any of those be optional? we might wish to make debug optional cos prod/staging loggers might not require those (but take note, also, that
winston-cloudwatch
hasdebug
but notfatal
) - what colour should we use on console logger? thinking blue for debug, bg red for fatal
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.
should any of those be optional?
Debug & fatal can be both optional
what colour should we use on console logger? thinking blue for debug, bg red for fatal
yea that's what we usually use, sounds good!
BLUE: "\x1b[34m%s\x1b[0m", | ||
}, | ||
BACKGROUND: { | ||
RED: "\x1b[41m%s\x1b[0m", |
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.
why is this a background.red?
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.
thinking blue for debug, bg red for fatal
like we agreed above, fatal should be background red, no? we already use foreground red for error
and this is more severe, so this is bg red.
Problem
Previously, our loggers were a thin wrapper over
CloudWatchLogger
and adding an external logging source was difficult. This was because our loggers depended on a concrete implementation rather than an interface.Closes IS-209
Solution
string
, the method takesstring | InternalError
Logger
interface + allows us to inject loggers into ituseFormatter
method to allow people to customise their log formats (idk if this should be on main or sub loggers ._. feel free to discuss)consoleLogger
in that is a simple object. prefixes w/ the level + has colours so it's obv.Tests
notes
init
function oncloudWatchLogger
was copied over as-is and this wasn't called previously but is now.formatter
was chosen to be placed on the main logger - we can change this if needed?const defaultImport = require("module")
had to be changed toconst defaultImport = require("module").default
due to how default imports work in es6 vs node (see here) for details.