feat: runtime logger formatting and debug verbose option #3067
Conversation
|
Thank you! we should switch from debug to consola. there are log level outputing in cosola. :) |
|
@kazupon |
|
@BobbieGoede |
|
Using the plugins used in https://github.com/vuetifyjs/nuxt-module as a reference, I think I have found a solution by using a virtual file that only imports consola if necessary, it comes with the added benefit of being able to import the logic in both the Nuxt and Nitro context. I barely understand how this works so I honestly don't know if there are any drawbacks or if this could have been made with a simpler approach. |
| @@ -49,20 +50,21 @@ export function parseAcceptLanguage(input: string): string[] { | |||
|
|
|||
| export function getBrowserLocale(): string | undefined { | |||
| let ret: string | undefined | |||
| const logger = /*#__PURE__*/ createLogger('getBrowserLocale') | |||
There was a problem hiding this comment.
We tag the logs with createLogger for each function, do we need to go that far? 😅
I think it would be better to have a logger tagged per js/ts module.
I believe we can make debugging more efficient from currently by filtering the logs by module.
There was a problem hiding this comment.
I agree it seems like a bit much, but most of the logs originally already had the function name in the log itself in each log statement (for example https://github.com/nuxt-modules/i18n/pull/3067/files/a44ce5dbcd40696e2cfd3db47b18464476a5cb45#diff-7755b40274cbd4ca5d224c6ed6953280e589110e9289595aeb246ff4a1c07448L57).
The primary reason for tagging them is so the actual code/logic is easier to read and understand (fewer multiline debug log statements, less word repetition). With these refactors I'm hoping to find patterns for simplification like in #3063.
Logging per module/file would definitely make more sense, and I think the fact that we had the function name in the logs probably means that internal.ts and utils.ts` are not descriptive enough, which we could solve by splitting these up further.
There was a problem hiding this comment.
The primary reason for tagging them is so the actual code/logic is easier to read and understand (fewer multiline debug log statements, less word repetition). With these refactors I'm hoping to find patterns for simplification like in #3063.
Okay, I could understand what you are trying to improve for logging. Let's continue to refactor and improve! :)
🔗 Linked issue
❓ Type of change
📚 Description
This changes the runtime debug logging to use a simple logger which prefixes each log with a label:
[i18n:${label}], and changes the logging slightly to make it less verbose.I have also changed the
debugoption to accept a string'verbose', now when enabling debug logging the loaded messages objects will not be logged by default but instead only fully log for verbose logging.The main purpose of this change is to make the debug logs a bit more consistent and allow for easier filtering (especially in the browser) but we could also explore adding basic filtering by label/namespace ourselves.
📝 Checklist