RFC: an objectMode stream implementation for winston
Transports
#2
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
The
winston@3
efforts have definitely crossed the 80% mark. This PR represents the final semantics forwinston-transport
base implementations:TransportStream
: the newobjectMode
Writable stream which should be the base for all future Transports afterwinston >= 3
.LegacyTransportStream
: the backwards compatible wrap to Transports written forwinston < 3
. There isn't all that much different for those implementors except thatlog(level, message, meta, callback)
is nowlog(info, callback)
whereinfo
is the object being plumbed along the objectMode pipe-chain. This was absolutely critical to not "break the ecosystem" and give the over 500 Transport package authors an upgrade path.Discuss
There are currently three outstanding items that warrant discussion:
Practical implications of implementing
._writev
:The current approach will be to make an optional
.logv
thatTransportStream
implementors can take advantage of if they wish. If.logv
does not exist then._writev
will call.log
multiple times.Formats for
TransportStream
instances:winston@3
Moves all of the log formatting into user-land and performs some plumbing in
.format
where it reads from the underlying_format
and._transform
where it writes to the_format
. We need to do this same bookkeeping inTransportStream
since there are obvious Transport-specific formatting choices (e.g. to colorize console output, but not file output).Pipe from multiple parent
Logger
instances:This will work no problem today, unless the parent
Logger
instances are configured with different levels. While this is technically possible fromwinston.Container
code paths, it is an unknown if the user-base is utilizing it. If you share Transports across multiple Loggers WITH DIFFERENT LEVELS please chime in here. Your input is necessary as we are strongly considering dropping this feature.Items for merge
TransportStream
LegacyTransportStream
_writev
forTransportStream
_writev
forLegacyTransportStream
format
onTransportStream