-
-
Notifications
You must be signed in to change notification settings - Fork 3.5k
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
feat(logger): simplify logger
API
#2344
Conversation
This pull request is being automatically deployed with Vercel (learn more). 🔍 Inspect: https://vercel.com/nextauthjs/next-auth/9REUgGGDfCkWgh9mdGaKguGRpAHu |
These adapter specific errors are now generated on-the-fly.
logger
API
Codecov Report
@@ Coverage Diff @@
## next #2344 +/- ##
==========================================
+ Coverage 10.78% 10.89% +0.10%
==========================================
Files 83 83
Lines 1409 1395 -14
Branches 389 389
==========================================
Hits 152 152
+ Misses 1042 1026 -16
- Partials 215 217 +2
Continue to review full report at Codecov.
|
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.
Super 💪🏽 💯
Similar to nextauthjs#2342, this aims to unify the user-facing API and provide an easier way to extend in the future. In addition, this PR also solves the problem when the `logger.error` method sometimes did not print results, because `Error` instances are not serializable and will be printed as empty objects `"{}"`. After this PR, we make any `Error` instances serializable as described here: https://iaincollins.medium.com/error-handling-in-javascript-a6172ccdf9af Closes nextauthjs#1602 Achieved by adding a `client: true` flag when logs are coming from the frontend. BREAKING CHANGE: The main change is that instead of an unknown number of parameters, the log events have at most two, where the second parameter is usually an object. In the case of the `error` event, it can also be an `Error` instance (that is serializable by `JSON.stringify`). If it is an object, an `Error` instance will be available on `metadata.error`, and `message` will default to `metadata.error.message`. This is done so that an error event always provides some kind of a stack to see where the error happened ```diff // [...nextauth.js] import log from "some-logger-service" ... logger: { - error(code, ...message) {}, + error(code, metadata) {}, - warn(code, ...message) {}, + warn(code) {} - debug(code, ...message) {} + debug(code, metadata) {} } ```
Similar to #2342, this aims to unify the user-facing API and provide an easier way to extend in the future.
In addition, this PR also solves the problem when the
logger.error
method sometimes did not print results, becauseError
instances are not serializable and will be printed as empty objects"{}"
.After this PR, we make any
Error
instances serializable as described here: https://iaincollins.medium.com/error-handling-in-javascript-a6172ccdf9afCloses #1602
Achieved by adding a
client: true
flag when logs are coming from the frontend.BREAKING CHANGE:
The main change is that instead of an unknown number of parameters, the log events have at most two, where the second parameter is usually an object. In the case of the
error
event, it can also be anError
instance (that is serializable byJSON.stringify
). If it is an object, anError
instance will be available onmetadata.error
, andmessage
will default tometadata.error.message
. This is done so that an error event always provides some kind of a stack to see where the error happened