Logging issues

[capps1994]

We have updated our Verdaccio instance, to 5.1.0 and now logging seems to be not working as expected.

In our logs we see {"level":25,"time":1623421647904,"pid":8,"hostname":"e643fb945f2c","request":{"method":"GET","url":"/-/verdaccio/packages"},"user":null,"remoteIP":"172.18.0.1","status":304,"bytes":{"in":0,"out":0},"msg":"@{status}, user: @{user}(@{remoteIP}), req: '@{request.method} @{request.url}', bytes: @{bytes.in}/@{bytes.out}"}

We have the following in our config logs:
- { type: stdout, format: pretty, level: http }

Has anything changed?

[juanpicado]

Do you refer to pretty? https://verdaccio.org/blog/#pretty-loggin

I can assume you have NODE_ENV=production and automatically fall back to json, it is more performant and will speed up your registry.

[juanpicado]

Nop, you can find detailed explanation here https://verdaccio.org/blog/2021/04/14/verdaccio-5-migration-guide#pretty-loggin

Recommendations, well nothing in special, just define your level, json directly for production and stdout is the faster one.

[edclement]

@juanpicado I was digging through the code to see why the placeholders (e.g. @{user}) are not being hydrated in the JSON formatted log messages as I had the same question as @capps1994. It seems based on:

1. Reviewing the logging code for the current stable 5.2.0 version (see here) and the latest 6.x code (see here)
2. The blog post you reference: https://verdaccio.org/blog/2021/04/14/verdaccio-5-migration-guide#pretty-loggin
3. Previous comments in this discussion

...That not hydrating the placeholder template strings when logging in JSON format is a conscious/purposeful decision.

I would ask why Verdaccio maintainers have decided to prioritize pretty print logging (development logging) functionality over production logging functionality? I personally feel like it is a bad idea to allow production logs to keep these un-hydrated template strings in the output as they provide no benefit, add extra noise to the logging output, and eat up log storage space (even if it is small).

Can I ask if there is a reason (performance or other) why the logic defined in the fillInMsgTemplate function can't be applied to the JSON log messages? I would be willing to open a PR to apply this same logic to the JSON log messages.

Going even further, given the fact that JavaScript features have progressed significantly since the original Verdaccio/Sinopia versions were written and features like template literals have been supported for quite some time, is there a good reason to continue to support the custom @{var} template placeholders?

[juanpicado]

Can I ask if there is a reason (performance or other) why the logic defined in the fillInMsgTemplate function can't be applied to the JSON log messages?

I think the reason is just a mistake, feel free to improve it.

Going even further, given the fact that JavaScript features have progressed significantly since the original Verdaccio/Sinopia versions were written and features like template literals have been supported for quite some time is there a good reason to continue to support the custom @{var} template placeholders?

No specific big reason, it just legacy that was never refactored, so if you help the project with a different approach I'll be happy to help you move it forward.

If you have noticed the 6.x is moving slow but trying to go in the right direction :) so happy you raised the flag here.

I'd suggest if you would like have this for 5.x to add a new option so is opt-in, I don't know if users are relying on the current format, for the next major we can do whatever is the best, no fear in break anything, we just need to document it correctly.

[edclement]

Thanks for the quick follow-up and explanations. I had assumed the issue was related to legacy [code] that was never refactored.

I'd suggest if you would like have this for 5.x to add a new option so is opt-in, I don't know if users are relying on the current format

If I open a PR to fix this in 5.x should I target the 5.x branch?

I'm assuming for 6.x I should target the master branch.

Thanks!

[juanpicado]

Yes, just be aware both branches have their own contributors guidelines, package manager etc etc ...