Configurable logging

[balazsorban44]

Summary of proposed feature
A clear and concise description of the feature being proposed.

Make it possible for the user to decide how/where to log messages by next-auth, on all level.

Purpose of proposed feature
A clear and concise description description of why this feature is necessary and what problems it solves.

next-auth already gives us the possibility to log some errors when they arise, through the
error event handler (although I am not sure when and where this is called, @iaincollins. I would even argue, that this proposal would make events.error unnecessary, but that would make the feature a breaking change. I need your opinion on this). I think we can get a bit further, if we make it possible for the user to decide where to send all the logs put out by next-auth. You see, when the Next.js app gets deployed somewhere, logging to the console will probably be lost or at least hard to reach. I propose a way for the user to get hold of those logs, and let them send it to somewhere else, like a third-party logging service.

Detail about proposed feature
A detailed description of how the proposal might work (if you have one).

Here is how I can see the user facing API, following the signatures of built-in console logger functions at https://github.com/nextauthjs/next-auth/blob/main/src/lib/logger.js:

import NextAuth from 'next-auth'
import myLogger from "my-logger"

const options = {
  logger: {
    error(params) {
      myLogger.error(params, "{code}: {text} ({link})")
    },
    warn(params) {
      myLogger.warn(params, "{code}: {text} ({link})")
    },
    debug(params) {
      myLogger.debug(params, "{code}: {text}")
    },
  }	as Logger
}

export default (req, res) => NextAuth(req, res, options)

interface LogParams {
  code: string
  text: string
  link?: string
}

// This is the form of the logger, not required by user, could be added to `@types/next-auth`
interface Logger {
  error?: (params: LogParams) => void
  warn?: (params: LogParams) => void
  debug?: (params: LogParams) => void
}

Here, when myLogger#{level} is called, it will send that message to a third party logging server.

Its implementation is less relevant than the signature of the logger methods, But here I provided the format which our logger takes. The first argument is an object, the second is the actual message, where I can reference values from the object. The message is shown first in our logger service, and on click it will also expand the object. In case myLogger has the same signature as logger expects, the user could simply do :

//...
import NextAuth from 'next-auth'
import myLogger from "my-logger"

const options = {
  logger: myLogger
}

export default (req, res) => NextAuth(req, res, options)

The idea is, that the user could provide as many of these methods as they want, so if they only define error inside logger, then warn and debug will keep logging to console. Or we could require the user to provide all 3 levels all the time, for consistency.

Potential problems
Describe any potential problems or potential limitations or caveats that might apply to the proposed solution.

This can be implemented in a backward-compatible way, so no problems arise.

Describe any alternatives you've considered

When having a problem with next-auth, I can only debug it locally, cause accessing the logs in our deployment environment is not always easy (For example a Docker container in Azure App Service)

Additional context
Any other context, screenshots, etc.

Please indicate if you are willing and able to help implement the proposed feature.

Implemented in #870

Would love to here your thoughts!

[github-actions]

🎉 This issue has been resolved in version 3.4.0 🎉

The release is available on:

• npm package (@latest dist-tag)
• GitHub release

Your semantic-release bot 📦🚀