New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Proposed handling of info[SPLAT] #1408
Comments
I worked on this last night and created a branch with code that implements the above. Let me know if you want me to create a PR in Logform for this. Here's a test file that I used...
with the following outputs...
|
Added support to my code for info.splat in addition to info[SPLAT]. |
Something like this is needed. Basically, if you cant upgrade to v3 without touching your existing log statements, AND be able to get meta as a SEPARATE object AFTER interpolation, then v3 is a non-starter for most exiting users. I have no idea why anyone thought it was a good idea to mix level, message, and meta into one big object. It is ripe for conflicts. info[Symbol.for('splat)] is also not reliable because it will mix interpolation values and meta together. We want meta SEPARATE. |
So I just realized that using format.splat() does add a meta object to the info, BUT only if you also used interpolation. If you dont use interpolation, the meta is just mixed into the info object. Also when using interpolation and meta, the format.simple() outputs the meta as {meta:{METAOBJ}} instead of just {METAOBJ} like v2. |
What's the feature?
This is a proposal for different handling of objects (JSON/array/other) for more versatile use cases.
In short, this proposal covers two things.
What problem is the feature intended to solve?
Various users (eg #1377, #1381, myself) have noted that treatment of objects/arrays is different in V3 from V2. In V2 these object types would be stored in the
options.meta
field and could be processed separately from the message and level and objects.In V3, there is only one scenario/transform in which options.meta gets processed the same as in V2. This is when using the logform.splat transform. Splat will correctly parse meta only when a token is present in the log. EG:
logger.log('info', 'this is a string I want to splat %s', 'together', {an: 'object'})
will result in:
info: this is a string I want to splat together {"meta":{"an":"object"}} // with .simple() transform
If users don't want to use logform.splat, info.meta will not be processed. Instead, the meta objects will be left untouched in info[SPLAT].
Adding a logform that copies all info[SPLAT] to info[meta] will both meet expectations of V2 users and be more flexible. (Alternatively, directly adding the info[SPLAT] to the logger output and providing documentation on info[meta] => info[SPLAT] could be acceptable.)
A new transform (eg logform.captureAllMeta just for naming sake) could be as simple as:
The equivalent of
would become
The extraSplat code could be removed from splat() as it is handled in the subsequent (new) transform.
An added benefit is if users don't want to use format.splat(), they can still include format.captureAllMeta() as a standalone transform.
Is the absence of this feature blocking you or your team? If so, how?
Now knowing that info[SPLAT] stores what is missing in info[meta], this could be considered a knowledge/documentation gap.
Is this feature similar to an existing feature in another tool?
Extends V2 to V3 compatibility.
Is this a feature you're prepared to implement, with support from us?
Yes, I can do my best to support this.
To reproduce the problem
winston
version?winston@2
winston@3
node -v
outputs: 6.10.0What is the problem?
Here is a sample of a V2 transport code with output:
In V3, I tried to replicate this with the following code, but the result did not display the array.
The text was updated successfully, but these errors were encountered: