[sitecore-jss-proxy] Configurable Loglevel

[monkey-ldb]

Is your feature request related to a problem? Please describe.

I only want to log error messages, no info/warn, but I can only configure debug=true/false.
There seems no other way to pass this parameter to the http proxy framework, which is used.

jss/packages/sitecore-jss-proxy/src/index.ts

Line 556 in af8d48c

logLevel: config.debug ? 'debug' : 'info',

Describe the solution you'd like

config parameter to pass the expected log level

Notes

Would be good if this feature will be added also to older versions, like 18.0

[ambrauer]

Hi @monkey-ldb. This is a great suggestion. I've added this to our backlog to prioritize.

We also gladly accept PRs if you're willing. Check the contributing guide as it has had recent updates and we'll be happy to merge it in.

[mjarosch]

Hi @ambrauer, I stumbled across this and was wondering if it is still on your backlog? Also, you mentioned accepting PRs, what is the rule about external libraries? Like using winston to re-implement and provide more advanced logging features?

[ambrauer]

Hi @mjarosch! Still in our backlog, but this particular log level is applicable only to the http-proxy-middleware used for @sitecore-jss/sitecore-jss-proxy package (I'll update the discussion title to make that clear). In all other SDK packages, JSS has standardized on use of the debug module for logging (see docs here for more details).

[mjarosch]

Hi @ambrauer, I am aware of the debug functionality. It has nice name-spacing, but is lacking the logging level and other advanced features.

[ambrauer]

@mjarosch We are pretty committed to debug at this point. The big draws here were the flexibility of name-spacing, the environment variable-based API, server/browser support, but also the general simplicity. I think log level could be implemented with debug (e.g. using a DEBUG_LEVEL variable) but so far have avoided introducing that level of complexity. Worth considering though. Beside log level, what other features would you be looking for?

[mjarosch]

@ambrauer The big missing feature is transports. We centralize our logs in an APM like AppInsights or Dynatrace. There isn't a great way to accomplish that with debug.

I do like the environment variable configuration, but Vercel requires a redeploy to pickup changes. Not a show stopper, but a big speed bump when troubleshooting. Although, being able to point your local at production experience edge data has been a game changer for debugging.

[ambrauer]

@mjarosch I should have mentioned one other advantage with debug is that because it does use the Web Standard console API, this automatically works on edge runtime. This is a requirement for Next.js but also a general expectation as the industry moves to serverless.

My take on transports is that this should be at a lower level (working directly with stderr or stdout) with a log drain approach. Most deployment platforms provide this feature (e.g. Vercel and Netlify). I can see how this would be more of a challenge for self-hosting though.