Closed arb closed 8 years ago
I was about to create something similar, so +1. Two questions:
.travis.yml
with the new versions should be enough if the code works.True, I forgot that. I'm open to anything, I just would like to avoid the case when one stream breaks because the other modifies the object.
I see no particular reason to recreate any of those "canonical" stream modules (generally, the mississippi modules), but I can think of no reason that they shouldn't be tested on recent versions of node. Looks like pumpify will work fine on node v4 and v5: https://travis-ci.org/devinivy/pumpify/builds/88802545 .
I guess first steps would be to open a PR there and see if we can get some better testing on newer versions of Node there.
Update I'm thinking that the interface should be an array of streams, and then another key that represents the end of the stream. This is so that the ends of the streams can implement an asynchronous stop
method. This would be useful for tear downs.
I'm having trouble with this change. Using glue this is how I registered a custom reporter:
plugin: {
register: 'good',
options: {
reporters: [{
reporter: reporter,
events: {
error: '*',
log: '*',
ops: '*',
request: '*',
response: '*'
}
}]
}
}
I'm struggling to find something that works with the new interface. Everything I try gives me errors. Looking at the example in the first post I would assume I would use:
plugin: {
register: 'good',
options: {
reporters: {
'my-stream': {
streams: [{
module: require ('../src/server/reporters/mongo'),
args: [{
error: '*',
log: '*',
ops: '*',
request: '*',
response: '*'
}]
}]
}
}
}
}
But that errors with: Error: Invalid monitorOptions options child "reporters" fails because [child "my-stream" fails because ["my-stream" must be an array]]
If I make it an array (it's not in the example) I get: Error: Invalid monitorOptions options child "reporters" fails because [child "my-stream" fails because ["my-stream" at position 0 does not match any of the allowed types]]
This issue was closed two months ago. If you are having problems, please open a new issue and don't bump old ones. That being said, you're probably using version 6 of good and not 7.
Either way, streams
doesn't seem to be a valid option to either good 6 or good 7.
No I'm using 7 and 7 was released with this breaking change 11 hours ago, but thanks so much for the help.
This thread has been automatically locked due to inactivity. Please open a new issue for related bugs or questions following the new issue template instructions.
I'm proposing that the new Good reporter interface allow users to pass an array of streams. Good would then create a stream pipeline with these streams. This would allow users to do things like use different filtering logic, clone the payloads before passing them on to other streams, and add additional implementation specific information.
I'm proposing the
reporters
option would look something like this:The
reporters
key will be a key/value pair. The key will be user friendly name that this reporter will be referred to. The value will be another object that has astreams
array. Each item in thestreams
array is an object. Themodule
value is either a path to a stream or a npm module to a stream object.constructor
is an optional string in cases where the stream constructor isn't the result ofrequire('module')
and is the function used to create a new stream. Finally,args
is an array of values passed to the constructor specified bymodule
. Each object inside the reporter object represents a stream object. When good starts, it will pipe each stream in the order of the items in the array, one into the next using pumpify.This will give good users much more control over how things are filtered, adding additional information to log messages, cloning, and other destination options.