provide ability to configure winston with pure data

[sramam]

I'd love for winston to provide an out-of-box way of configuration with pure data. Currently, it's a mix of js/js-object that makes treating it as config a little inflexible, especially when one is composing many layers of modules that all use logging in some capacity.

(Disclaimer: I am the author of winston-cfg, which tints my view.)

I really like using winston for node/js logging needs. The large number of transports make winston much more attractive in comparison to alternatives.

While some of the run-time configuration of winston can be very useful to isolate pesky bugs, my usage is typically restricted to well defined logs levels, used consistently through an application and sub-modules. I do see a need for various log configuration based on different environments.

For example, in dev. a File transport is great, but in production, I'd like these to use Cloud-Watch. Another example would be a CLI wrapper of a library logs to a file, but usage as a sub-module uses the logger of the parent application.

In all cases, I'd like the logger configuration to be independent of the module-in-use.

I prefer to use config to feed this in, but that's an orthogonal decision. Something like rc will work just as well.

Wondering if there is appetite in either building this independently as part of the winston module tree? I'm happy to take a stab at it, but would appreciate a critique of winston-cfg before digging too much deeper.

[indexzero]

I support this idea. There was also https://github.com/segmentio/winston-logger from a few years ago. How different is winston-cfg from that? Also: how would one configure custom formats that are essentially anonymous functions?

[sramam]

Interesting. I don't recall encountering winston-logger in my search, but did look at winston-config.

It's been a while, so I had to relook them up, but both have deficiencies towards a general-purpose data-driven configuration for winston. In addition to both having been relatively inactive at the point I embarked on winston-cfg.

winston-logger: only has support for a fixed number of transports. winston-cfg specifically allows for extensible transports via the transport-map mechanism, importantly this is decided by application. The transport map can be provided in the config itself, or in application code. My preferred option is to use node-config, which allows uses js/json or some other formats.

This is a bit of a cop-out however - because it muddies the data/code boundary, but even so many months later, not sure there is a better answer to finding external modules in a configuration for a base/root module.

winston-config: Seems to only support loggers, and a limited set at that. transports would have to be bolted on.

I wanted to get something going for the project at hand, and wanted to move in a big hurry to have a solution so decided to get things working within winston-cfg.

The intent was to reconcile the various approaches into one at a later point - if possible within Winston itself. Looking at 3.0 and the request for feedback, this issue was a means to follow through.

From my cursory understanding of the 3.0 changes, it would actually make it harder to port something like winston-cfg to 3.0. But again, cursory understanding is the operative sentiment.

Hope this provides some context.

[edits: some typos and rephrasing for clarity]

[sramam]

I am not sure this is the best course of action, but in my attempt to learn RxJs, I built a logger inspired by winston, unimaginatively called winston-rx.

The name is temporary, since I am unsure of how to proceed. Some possibilities:

• attempt to request merging such ideas into winston,
• create an independent logger or
• just let it die.

Perhaps it's a NIH syndrome, but I find winston-rx to be much simpler, while providing first class data driven configuration. It does do a bit lesser than what winston currently does, but most of that is fixable.

To illustrate the difference, both for simplicity, data-configurability and actually greater power of winston-rx, take the capability provided by logform for winston@3.0. winston-rx does not provide such ability. However, it's trivial to use a data driven transport to be attached to a given logger at run time, post initialization., giving one a similar capability. If the application can watch it's config and reload the configuration, transports with different config can be added post launch - ideally without application down-time. With logform, actual application code will need modification(s).

A few things not yet in winston-rx: profile and tailing capabilities. One of the features I am very interested in is a multi-line spinner that is just another transport. Though that is a little more nebulous.

I'm happy to discuss further - or if my crazy ideas seem disruptive to the mission of Winston, please let me know and I'll stop bothering y'all.

[DanKaplanSES]

I have some thoughts but I don't want to detract this thread if they are off topic: Before finding this issue, I created a stack overflow question that might be related: How do you configure a 3rd party library's Winston loggers?. I say "might be related" because it's hard for me tell. This issue is about configuring winston with data, but—correct me if I'm wrong—for a different purpose: reducing the code/boilerplate/DRY violations of configuring loggers in a large project.

My motivation, on the other hand, is to config logging in 3rd party dependencies. It's not necessary that this configuration is done with data, but that's the implementation I had in mind.

Circling back to my first sentence, should I create a new issue for this or continue the conversation here?