react-hook-eslint 1.0.1
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/CONTRIBUTING.md +30 -0
- package/LICENSE +21 -0
- package/README.md +85 -0
- package/SECURITY.md +68 -0
- package/docs/api.md +1487 -0
- package/docs/asynchronous.md +40 -0
- package/docs/benchmarks.md +55 -0
- package/docs/browser.md +227 -0
- package/docs/bundling.md +40 -0
- package/docs/child-loggers.md +95 -0
- package/docs/ecosystem.md +84 -0
- package/docs/help.md +345 -0
- package/docs/lts.md +64 -0
- package/docs/pretty.md +35 -0
- package/docs/redaction.md +135 -0
- package/docs/transports.md +1238 -0
- package/docs/web.md +269 -0
- package/docsify/sidebar.md +26 -0
- package/favicon-16x16.png +0 -0
- package/favicon-32x32.png +0 -0
- package/favicon.ico +0 -0
- package/file.js +12 -0
- package/index.html +55 -0
- package/lib/caller.js +30 -0
- package/lib/constants.js +28 -0
- package/lib/deprecations.js +8 -0
- package/lib/levels.js +241 -0
- package/lib/meta.js +3 -0
- package/lib/multistream.js +188 -0
- package/lib/proto.js +234 -0
- package/lib/redaction.js +118 -0
- package/lib/symbols.js +74 -0
- package/lib/time.js +11 -0
- package/lib/tools.js +394 -0
- package/lib/transport-stream.js +56 -0
- package/lib/transport.js +167 -0
- package/lib/worker.js +194 -0
- package/lib/writer.js +44 -0
- package/package.json +38 -0
- package/pino-banner.png +0 -0
- package/pino-logo-hire.png +0 -0
- package/pino-tree.png +0 -0
- package/pino.d.ts +889 -0
- package/pino.js +38 -0
- package/pretty-demo.png +0 -0
- package/tsconfig.json +14 -0
@@ -0,0 +1,40 @@
|
|
1
|
+
# Asynchronous Logging
|
2
|
+
|
3
|
+
Asynchronous logging enables the minimum overhead of Pino.
|
4
|
+
Asynchronous logging works by buffering log messages and writing them in larger chunks.
|
5
|
+
|
6
|
+
```js
|
7
|
+
const pino = require('pino')
|
8
|
+
const logger = pino(pino.destination({
|
9
|
+
dest: './my-file', // omit for stdout
|
10
|
+
minLength: 4096, // Buffer before writing
|
11
|
+
sync: false // Asynchronous logging
|
12
|
+
}))
|
13
|
+
```
|
14
|
+
|
15
|
+
It's always possible to turn on synchronous logging by passing `sync: true`.
|
16
|
+
In this mode of operation, log messages are directly written to the
|
17
|
+
output stream as the messages are generated with a _blocking_ operation.
|
18
|
+
|
19
|
+
* See [`pino.destination`](/docs/api.md#pino-destination)
|
20
|
+
* `pino.destination` is implemented on [`sonic-boom` ⇗](https://github.com/mcollina/sonic-boom).
|
21
|
+
|
22
|
+
### AWS Lambda
|
23
|
+
|
24
|
+
Asynchronous logging is disabled by default on AWS Lambda or any other environment
|
25
|
+
that modifies `process.stdout`. If forcefully turned on, we recommend calling `dest.flushSync()` at the end
|
26
|
+
of each function execution to avoid losing data.
|
27
|
+
|
28
|
+
## Caveats
|
29
|
+
|
30
|
+
Asynchronous logging has a couple of important caveats:
|
31
|
+
|
32
|
+
* As opposed to the synchronous mode, there is not a one-to-one relationship between
|
33
|
+
calls to logging methods (e.g. `logger.info`) and writes to a log file
|
34
|
+
* There is a possibility of the most recently buffered log messages being lost
|
35
|
+
in case of a system failure, e.g. a power cut.
|
36
|
+
|
37
|
+
See also:
|
38
|
+
|
39
|
+
* [`pino.destination` API](/docs/api.md#pino-destination)
|
40
|
+
* [`destination` parameter](/docs/api.md#destination)
|
@@ -0,0 +1,55 @@
|
|
1
|
+
|
2
|
+
# Benchmarks
|
3
|
+
|
4
|
+
`pino.info('hello world')`:
|
5
|
+
|
6
|
+
```
|
7
|
+
|
8
|
+
BASIC benchmark averages
|
9
|
+
Bunyan average: 377.434ms
|
10
|
+
Winston average: 270.249ms
|
11
|
+
Bole average: 172.690ms
|
12
|
+
Debug average: 220.527ms
|
13
|
+
LogLevel average: 222.802ms
|
14
|
+
Pino average: 114.801ms
|
15
|
+
PinoMinLength average: 70.968ms
|
16
|
+
PinoNodeStream average: 159.192ms
|
17
|
+
|
18
|
+
```
|
19
|
+
|
20
|
+
`pino.info({'hello': 'world'})`:
|
21
|
+
|
22
|
+
```
|
23
|
+
|
24
|
+
OBJECT benchmark averages
|
25
|
+
BunyanObj average: 410.379ms
|
26
|
+
WinstonObj average: 273.120ms
|
27
|
+
BoleObj average: 185.069ms
|
28
|
+
LogLevelObject average: 433.425ms
|
29
|
+
PinoObj average: 119.315ms
|
30
|
+
PinoMinLengthObj average: 76.968ms
|
31
|
+
PinoNodeStreamObj average: 164.268ms
|
32
|
+
|
33
|
+
```
|
34
|
+
|
35
|
+
`pino.info(aBigDeeplyNestedObject)`:
|
36
|
+
|
37
|
+
```
|
38
|
+
|
39
|
+
DEEP-OBJECT benchmark averages
|
40
|
+
BunyanDeepObj average: 1.839ms
|
41
|
+
WinstonDeepObj average: 5.604ms
|
42
|
+
BoleDeepObj average: 3.422ms
|
43
|
+
LogLevelDeepObj average: 11.716ms
|
44
|
+
PinoDeepObj average: 2.256ms
|
45
|
+
PinoMinLengthDeepObj average: 2.240ms
|
46
|
+
PinoNodeStreamDeepObj average: 2.595ms
|
47
|
+
|
48
|
+
```
|
49
|
+
|
50
|
+
`pino.info('hello %s %j %d', 'world', {obj: true}, 4, {another: 'obj'})`:
|
51
|
+
|
52
|
+
For a fair comparison, [LogLevel](http://npm.im/loglevel) was extended
|
53
|
+
to include a timestamp and [bole](http://npm.im/bole) had
|
54
|
+
`fastTime` mode switched on.
|
55
|
+
|
package/docs/browser.md
ADDED
@@ -0,0 +1,227 @@
|
|
1
|
+
# Browser API
|
2
|
+
|
3
|
+
Pino is compatible with [`browserify`](https://npm.im/browserify) for browser-side usage:
|
4
|
+
|
5
|
+
This can be useful with isomorphic/universal JavaScript code.
|
6
|
+
|
7
|
+
By default, in the browser,
|
8
|
+
`pino` uses corresponding [Log4j](https://en.wikipedia.org/wiki/Log4j) `console` methods (`console.error`, `console.warn`, `console.info`, `console.debug`, `console.trace`) and uses `console.error` for any `fatal` level logs.
|
9
|
+
|
10
|
+
## Options
|
11
|
+
|
12
|
+
Pino can be passed a `browser` object in the options object,
|
13
|
+
which can have the following properties:
|
14
|
+
|
15
|
+
### `asObject` (Boolean)
|
16
|
+
|
17
|
+
```js
|
18
|
+
const pino = require('pino')({browser: {asObject: true}})
|
19
|
+
```
|
20
|
+
|
21
|
+
The `asObject` option will create a pino-like log object instead of
|
22
|
+
passing all arguments to a console method, for instance:
|
23
|
+
|
24
|
+
```js
|
25
|
+
pino.info('hi') // creates and logs {msg: 'hi', level: 30, time: <ts>}
|
26
|
+
```
|
27
|
+
|
28
|
+
When `write` is set, `asObject` will always be `true`.
|
29
|
+
|
30
|
+
### `formatters` (Object)
|
31
|
+
|
32
|
+
An object containing functions for formatting the shape of the log lines. When provided, it enables the logger to produce a pino-like log object with customized formatting. Currently, it supports formatting for the `level` object only.
|
33
|
+
|
34
|
+
##### `level`
|
35
|
+
|
36
|
+
Changes the shape of the log level. The default shape is `{ level: number }`.
|
37
|
+
The function takes two arguments, the label of the level (e.g. `'info'`)
|
38
|
+
and the numeric value (e.g. `30`).
|
39
|
+
|
40
|
+
```js
|
41
|
+
const formatters = {
|
42
|
+
level (label, number) {
|
43
|
+
return { level: number }
|
44
|
+
}
|
45
|
+
}
|
46
|
+
```
|
47
|
+
|
48
|
+
|
49
|
+
### `write` (Function | Object)
|
50
|
+
|
51
|
+
Instead of passing log messages to `console.log` they can be passed to
|
52
|
+
a supplied function.
|
53
|
+
|
54
|
+
If `write` is set to a single function, all logging objects are passed
|
55
|
+
to this function.
|
56
|
+
|
57
|
+
```js
|
58
|
+
const pino = require('pino')({
|
59
|
+
browser: {
|
60
|
+
write: (o) => {
|
61
|
+
// do something with o
|
62
|
+
}
|
63
|
+
}
|
64
|
+
})
|
65
|
+
```
|
66
|
+
|
67
|
+
If `write` is an object, it can have methods that correspond to the
|
68
|
+
levels. When a message is logged at a given level, the corresponding
|
69
|
+
method is called. If a method isn't present, the logging falls back
|
70
|
+
to using the `console`.
|
71
|
+
|
72
|
+
|
73
|
+
```js
|
74
|
+
const pino = require('pino')({
|
75
|
+
browser: {
|
76
|
+
write: {
|
77
|
+
info: function (o) {
|
78
|
+
//process info log object
|
79
|
+
},
|
80
|
+
error: function (o) {
|
81
|
+
//process error log object
|
82
|
+
}
|
83
|
+
}
|
84
|
+
}
|
85
|
+
})
|
86
|
+
```
|
87
|
+
|
88
|
+
### `serialize`: (Boolean | Array)
|
89
|
+
|
90
|
+
The serializers provided to `pino` are ignored by default in the browser, including
|
91
|
+
the standard serializers provided with Pino. Since the default destination for log
|
92
|
+
messages is the console, values such as `Error` objects are enhanced for inspection,
|
93
|
+
which they otherwise wouldn't be if the Error serializer was enabled.
|
94
|
+
|
95
|
+
We can turn all serializers on,
|
96
|
+
|
97
|
+
```js
|
98
|
+
const pino = require('pino')({
|
99
|
+
browser: {
|
100
|
+
serialize: true
|
101
|
+
}
|
102
|
+
})
|
103
|
+
```
|
104
|
+
|
105
|
+
Or we can selectively enable them via an array:
|
106
|
+
|
107
|
+
```js
|
108
|
+
const pino = require('pino')({
|
109
|
+
serializers: {
|
110
|
+
custom: myCustomSerializer,
|
111
|
+
another: anotherSerializer
|
112
|
+
},
|
113
|
+
browser: {
|
114
|
+
serialize: ['custom']
|
115
|
+
}
|
116
|
+
})
|
117
|
+
// following will apply myCustomSerializer to the custom property,
|
118
|
+
// but will not apply anotherSerializer to another key
|
119
|
+
pino.info({custom: 'a', another: 'b'})
|
120
|
+
```
|
121
|
+
|
122
|
+
When `serialize` is `true` the standard error serializer is also enabled (see https://github.com/pinojs/pino/blob/master/docs/api.md#stdSerializers).
|
123
|
+
This is a global serializer, which will apply to any `Error` objects passed to the logger methods.
|
124
|
+
|
125
|
+
If `serialize` is an array the standard error serializer is also automatically enabled, it can
|
126
|
+
be explicitly disabled by including a string in the serialize array: `!stdSerializers.err`, like so:
|
127
|
+
|
128
|
+
```js
|
129
|
+
const pino = require('pino')({
|
130
|
+
serializers: {
|
131
|
+
custom: myCustomSerializer,
|
132
|
+
another: anotherSerializer
|
133
|
+
},
|
134
|
+
browser: {
|
135
|
+
serialize: ['!stdSerializers.err', 'custom'] //will not serialize Errors, will serialize `custom` keys
|
136
|
+
}
|
137
|
+
})
|
138
|
+
```
|
139
|
+
|
140
|
+
The `serialize` array also applies to any child logger serializers (see https://github.com/pinojs/pino/blob/master/docs/api.md#discussion-2
|
141
|
+
for how to set child-bound serializers).
|
142
|
+
|
143
|
+
Unlike server pino the serializers apply to every object passed to the logger method,
|
144
|
+
if the `asObject` option is `true`, this results in the serializers applying to the
|
145
|
+
first object (as in server pino).
|
146
|
+
|
147
|
+
For more info on serializers see https://github.com/pinojs/pino/blob/master/docs/api.md#mergingobject.
|
148
|
+
|
149
|
+
### `transmit` (Object)
|
150
|
+
|
151
|
+
An object with `send` and `level` properties.
|
152
|
+
|
153
|
+
The `transmit.level` property specifies the minimum level (inclusive) of when the `send` function
|
154
|
+
should be called, if not supplied the `send` function be called based on the main logging `level`
|
155
|
+
(set via `options.level`, defaulting to `info`).
|
156
|
+
|
157
|
+
The `transmit` object must have a `send` function which will be called after
|
158
|
+
writing the log message. The `send` function is passed the level of the log
|
159
|
+
message and a `logEvent` object.
|
160
|
+
|
161
|
+
The `logEvent` object is a data structure representing a log message, it represents
|
162
|
+
the arguments passed to a logger statement, the level
|
163
|
+
at which they were logged, and the hierarchy of child bindings.
|
164
|
+
|
165
|
+
The `logEvent` format is structured like so:
|
166
|
+
|
167
|
+
```js
|
168
|
+
{
|
169
|
+
ts = Number,
|
170
|
+
messages = Array,
|
171
|
+
bindings = Array,
|
172
|
+
level: { label = String, value = Number}
|
173
|
+
}
|
174
|
+
```
|
175
|
+
|
176
|
+
The `ts` property is a Unix epoch timestamp in milliseconds, the time is taken from the moment the
|
177
|
+
logger method is called.
|
178
|
+
|
179
|
+
The `messages` array is all arguments passed to logger method, (for instance `logger.info('a', 'b', 'c')`
|
180
|
+
would result in `messages` array `['a', 'b', 'c']`).
|
181
|
+
|
182
|
+
The `bindings` array represents each child logger (if any), and the relevant bindings.
|
183
|
+
For instance, given `logger.child({a: 1}).child({b: 2}).info({c: 3})`, the bindings array
|
184
|
+
would hold `[{a: 1}, {b: 2}]` and the `messages` array would be `[{c: 3}]`. The `bindings`
|
185
|
+
are ordered according to their position in the child logger hierarchy, with the lowest index
|
186
|
+
being the top of the hierarchy.
|
187
|
+
|
188
|
+
By default, serializers are not applied to log output in the browser, but they will *always* be
|
189
|
+
applied to `messages` and `bindings` in the `logEvent` object. This allows us to ensure a consistent
|
190
|
+
format for all values between server and client.
|
191
|
+
|
192
|
+
The `level` holds the label (for instance `info`), and the corresponding numerical value
|
193
|
+
(for instance `30`). This could be important in cases where client-side level values and
|
194
|
+
labels differ from server-side.
|
195
|
+
|
196
|
+
The point of the `send` function is to remotely record log messages:
|
197
|
+
|
198
|
+
```js
|
199
|
+
const pino = require('pino')({
|
200
|
+
browser: {
|
201
|
+
transmit: {
|
202
|
+
level: 'warn',
|
203
|
+
send: function (level, logEvent) {
|
204
|
+
if (level === 'warn') {
|
205
|
+
// maybe send the logEvent to a separate endpoint
|
206
|
+
// or maybe analyze the messages further before sending
|
207
|
+
}
|
208
|
+
// we could also use the `logEvent.level.value` property to determine
|
209
|
+
// numerical value
|
210
|
+
if (logEvent.level.value >= 50) { // covers error and fatal
|
211
|
+
|
212
|
+
// send the logEvent somewhere
|
213
|
+
}
|
214
|
+
}
|
215
|
+
}
|
216
|
+
}
|
217
|
+
})
|
218
|
+
```
|
219
|
+
|
220
|
+
### `disabled` (Boolean)
|
221
|
+
|
222
|
+
```js
|
223
|
+
const pino = require('pino')({browser: {disabled: true}})
|
224
|
+
```
|
225
|
+
|
226
|
+
The `disabled` option will disable logging in browser if set
|
227
|
+
to `true`, by default it is set to `false`.
|
package/docs/bundling.md
ADDED
@@ -0,0 +1,40 @@
|
|
1
|
+
# Bundling
|
2
|
+
|
3
|
+
Due to its internal architecture based on Worker Threads, it is not possible to bundle Pino *without* generating additional files.
|
4
|
+
|
5
|
+
In particular, a bundler must ensure that the following files are also bundled separately:
|
6
|
+
|
7
|
+
* `lib/worker.js` from the `thread-stream` dependency
|
8
|
+
* `file.js`
|
9
|
+
* `lib/worker.js`
|
10
|
+
* Any transport used by the user (like `pino-pretty`)
|
11
|
+
|
12
|
+
Once the files above have been generated, the bundler must also add information about the files above by injecting a code that sets `__bundlerPathsOverrides` in the `globalThis` object.
|
13
|
+
|
14
|
+
The variable is an object whose keys are an identifier for the files and the values are the paths of files relative to the currently bundle files.
|
15
|
+
|
16
|
+
Example:
|
17
|
+
|
18
|
+
```javascript
|
19
|
+
// Inject this using your bundle plugin
|
20
|
+
globalThis.__bundlerPathsOverrides = {
|
21
|
+
'thread-stream-worker': pinoWebpackAbsolutePath('./thread-stream-worker.js')
|
22
|
+
'pino/file': pinoWebpackAbsolutePath('./pino-file.js'),
|
23
|
+
'pino-worker': pinoWebpackAbsolutePath('./pino-worker.js'),
|
24
|
+
'pino-pretty': pinoWebpackAbsolutePath('./pino-pretty.js'),
|
25
|
+
};
|
26
|
+
```
|
27
|
+
|
28
|
+
Note that `pino/file`, `pino-worker` and `thread-stream-worker` are required identifiers. Other identifiers are possible based on the user configuration.
|
29
|
+
|
30
|
+
## Webpack Plugin
|
31
|
+
|
32
|
+
If you are a Webpack user, you can achieve this with [pino-webpack-plugin](https://github.com/pinojs/pino-webpack-plugin) without manual configuration of `__bundlerPathsOverrides`; however, you still need to configure it manually if you are using other bundlers.
|
33
|
+
|
34
|
+
## Esbuild Plugin
|
35
|
+
|
36
|
+
[esbuild-plugin-pino](https://github.com/davipon/esbuild-plugin-pino) is the esbuild plugin to generate extra pino files for bundling.
|
37
|
+
|
38
|
+
## Bun Plugin
|
39
|
+
|
40
|
+
[bun-plugin-pino](https://github.com/vktrl/bun-plugin-pino) is the Bun plugin to generate extra pino files for bundling.
|
@@ -0,0 +1,95 @@
|
|
1
|
+
# Child loggers
|
2
|
+
|
3
|
+
Let's assume we want to have `"module":"foo"` added to every log within a
|
4
|
+
module `foo.js`.
|
5
|
+
|
6
|
+
To accomplish this, simply use a child logger:
|
7
|
+
|
8
|
+
```js
|
9
|
+
'use strict'
|
10
|
+
// imports a pino logger instance of `require('pino')()`
|
11
|
+
const parentLogger = require('./lib/logger')
|
12
|
+
const log = parentLogger.child({module: 'foo'})
|
13
|
+
|
14
|
+
function doSomething () {
|
15
|
+
log.info('doSomething invoked')
|
16
|
+
}
|
17
|
+
|
18
|
+
module.exports = {
|
19
|
+
doSomething
|
20
|
+
}
|
21
|
+
```
|
22
|
+
|
23
|
+
## Cost of child logging
|
24
|
+
|
25
|
+
Child logger creation is fast:
|
26
|
+
|
27
|
+
```
|
28
|
+
benchBunyanCreation*10000: 564.514ms
|
29
|
+
benchBoleCreation*10000: 283.276ms
|
30
|
+
benchPinoCreation*10000: 258.745ms
|
31
|
+
benchPinoExtremeCreation*10000: 150.506ms
|
32
|
+
```
|
33
|
+
|
34
|
+
Logging through a child logger has little performance penalty:
|
35
|
+
|
36
|
+
```
|
37
|
+
benchBunyanChild*10000: 556.275ms
|
38
|
+
benchBoleChild*10000: 288.124ms
|
39
|
+
benchPinoChild*10000: 231.695ms
|
40
|
+
benchPinoExtremeChild*10000: 122.117ms
|
41
|
+
```
|
42
|
+
|
43
|
+
Logging via the child logger of a child logger also has negligible overhead:
|
44
|
+
|
45
|
+
```
|
46
|
+
benchBunyanChildChild*10000: 559.082ms
|
47
|
+
benchPinoChildChild*10000: 229.264ms
|
48
|
+
benchPinoExtremeChildChild*10000: 127.753ms
|
49
|
+
```
|
50
|
+
|
51
|
+
## Duplicate keys caveat
|
52
|
+
|
53
|
+
Naming conflicts can arise between child loggers and
|
54
|
+
children of child loggers.
|
55
|
+
|
56
|
+
This isn't as bad as it sounds, even if the same keys between
|
57
|
+
parent and child loggers are used, Pino resolves the conflict in the sanest way.
|
58
|
+
|
59
|
+
For example, consider the following:
|
60
|
+
|
61
|
+
```js
|
62
|
+
const pino = require('pino')
|
63
|
+
pino(pino.destination('./my-log'))
|
64
|
+
.child({a: 'property'})
|
65
|
+
.child({a: 'prop'})
|
66
|
+
.info('howdy')
|
67
|
+
```
|
68
|
+
|
69
|
+
```sh
|
70
|
+
$ cat my-log
|
71
|
+
{"pid":95469,"hostname":"MacBook-Pro-3.home","level":30,"msg":"howdy","time":1459534114473,"a":"property","a":"prop"}
|
72
|
+
```
|
73
|
+
|
74
|
+
Notice how there are two keys named `a` in the JSON output. The sub-child's properties
|
75
|
+
appear after the parent child properties.
|
76
|
+
|
77
|
+
At some point, the logs will most likely be processed (for instance with a [transport](transports.md)),
|
78
|
+
and this generally involves parsing. `JSON.parse` will return an object where the conflicting
|
79
|
+
namespace holds the final value assigned to it:
|
80
|
+
|
81
|
+
```sh
|
82
|
+
$ cat my-log | node -e "process.stdin.once('data', (line) => console.log(JSON.stringify(JSON.parse(line))))"
|
83
|
+
{"pid":95469,"hostname":"MacBook-Pro-3.home","level":30,"msg":"howdy","time":"2016-04-01T18:08:34.473Z","a":"prop"}
|
84
|
+
```
|
85
|
+
|
86
|
+
Ultimately the conflict is resolved by taking the last value, which aligns with Bunyan's child logging
|
87
|
+
behavior.
|
88
|
+
|
89
|
+
There may be cases where this edge case becomes problematic if a JSON parser with alternative behavior
|
90
|
+
is used to process the logs. It's recommended to be conscious of namespace conflicts with child loggers,
|
91
|
+
in light of an expected log processing approach.
|
92
|
+
|
93
|
+
One of Pino's performance tricks is to avoid building objects and stringifying
|
94
|
+
them, so we're building strings instead. This is why duplicate keys between
|
95
|
+
parents and children will end up in the log output.
|
@@ -0,0 +1,84 @@
|
|
1
|
+
# Pino Ecosystem
|
2
|
+
|
3
|
+
This is a list of ecosystem modules that integrate with `pino`.
|
4
|
+
|
5
|
+
Modules listed under [Core](#core) are maintained by the Pino team. Modules
|
6
|
+
listed under [Community](#community) are maintained by independent community
|
7
|
+
members.
|
8
|
+
|
9
|
+
Please send a PR to add new modules!
|
10
|
+
|
11
|
+
<a id="core"></a>
|
12
|
+
## Core
|
13
|
+
|
14
|
+
### Frameworks
|
15
|
+
+ [`express-pino-logger`](https://github.com/pinojs/express-pino-logger): use
|
16
|
+
Pino to log requests within [express](https://expressjs.com/).
|
17
|
+
+ [`koa-pino-logger`](https://github.com/pinojs/koa-pino-logger): use Pino to
|
18
|
+
log requests within [Koa](https://koajs.com/).
|
19
|
+
+ [`restify-pino-logger`](https://github.com/pinojs/restify-pino-logger): use
|
20
|
+
Pino to log requests within [restify](http://restify.com/).
|
21
|
+
+ [`rill-pino-logger`](https://github.com/pinojs/rill-pino-logger): use Pino as
|
22
|
+
the logger for the [Rill framework](https://rill.site/).
|
23
|
+
|
24
|
+
### Utilities
|
25
|
+
+ [`pino-arborsculpture`](https://github.com/pinojs/pino-arborsculpture): change
|
26
|
+
log levels at runtime.
|
27
|
+
+ [`pino-caller`](https://github.com/pinojs/pino-caller): add callsite to the log line.
|
28
|
+
+ [`pino-clf`](https://github.com/pinojs/pino-clf): reformat Pino logs into
|
29
|
+
Common Log Format.
|
30
|
+
+ [`pino-debug`](https://github.com/pinojs/pino-debug): use Pino to interpret
|
31
|
+
[`debug`](https://npm.im/debug) logs.
|
32
|
+
+ [`pino-elasticsearch`](https://github.com/pinojs/pino-elasticsearch): send
|
33
|
+
Pino logs to an Elasticsearch instance.
|
34
|
+
+ [`pino-eventhub`](https://github.com/pinojs/pino-eventhub): send Pino logs
|
35
|
+
to an [Event Hub](https://docs.microsoft.com/en-us/azure/event-hubs/event-hubs-what-is-event-hubs).
|
36
|
+
+ [`pino-filter`](https://github.com/pinojs/pino-filter): filter Pino logs in
|
37
|
+
the same fashion as the [`debug`](https://npm.im/debug) module.
|
38
|
+
+ [`pino-gelf`](https://github.com/pinojs/pino-gelf): reformat Pino logs into
|
39
|
+
GELF format for Graylog.
|
40
|
+
+ [`pino-hapi`](https://github.com/pinojs/hapi-pino): use Pino as the logger
|
41
|
+
for [Hapi](https://hapijs.com/).
|
42
|
+
+ [`pino-http`](https://github.com/pinojs/pino-http): easily use Pino to log
|
43
|
+
requests with the core `http` module.
|
44
|
+
+ [`pino-http-print`](https://github.com/pinojs/pino-http-print): reformat Pino
|
45
|
+
logs into traditional [HTTPD](https://httpd.apache.org/) style request logs.
|
46
|
+
+ [`pino-mongodb`](https://github.com/pinojs/pino-mongodb): store Pino logs
|
47
|
+
in a MongoDB database.
|
48
|
+
+ [`pino-multi-stream`](https://github.com/pinojs/pino-multi-stream): send
|
49
|
+
logs to multiple destination streams (slow!).
|
50
|
+
+ [`pino-noir`](https://github.com/pinojs/pino-noir): redact sensitive information
|
51
|
+
in logs.
|
52
|
+
+ [`pino-pretty`](https://github.com/pinojs/pino-pretty): basic prettifier to
|
53
|
+
make log lines human-readable.
|
54
|
+
+ [`pino-socket`](https://github.com/pinojs/pino-socket): send logs to TCP or UDP
|
55
|
+
destinations.
|
56
|
+
+ [`pino-std-serializers`](https://github.com/pinojs/pino-std-serializers): the
|
57
|
+
core object serializers used within Pino.
|
58
|
+
+ [`pino-syslog`](https://github.com/pinojs/pino-syslog): reformat Pino logs
|
59
|
+
to standard syslog format.
|
60
|
+
+ [`pino-tee`](https://github.com/pinojs/pino-tee): pipe Pino logs into files
|
61
|
+
based upon log levels.
|
62
|
+
+ [`pino-test`](https://github.com/pinojs/pino-test): a set of utilities for
|
63
|
+
verifying logs generated by the Pino logger.
|
64
|
+
+ [`pino-toke`](https://github.com/pinojs/pino-toke): reformat Pino logs
|
65
|
+
according to a given format string.
|
66
|
+
|
67
|
+
|
68
|
+
<a id="community"></a>
|
69
|
+
## Community
|
70
|
+
|
71
|
+
+ [`@google-cloud/pino-logging-gcp-config`](https://www.npmjs.com/package/@google-cloud/pino-logging-gcp-config): Config helper and formatter to output [Google Cloud Platform Structured Logging](https://cloud.google.com/logging/docs/structured-logging)
|
72
|
+
+ [`@newrelic/pino-enricher`](https://github.com/newrelic/newrelic-node-log-extensions/blob/main/packages/pino-log-enricher): a log customization to add New Relic context to use [Logs In Context](https://docs.newrelic.com/docs/logs/logs-context/logs-in-context/)
|
73
|
+
+ [`cloud-pine`](https://github.com/metcoder95/cloud-pine): transport that provides abstraction and compatibility with [`@google-cloud/logging`](https://www.npmjs.com/package/@google-cloud/logging).
|
74
|
+
+ [`cls-proxify`](https://github.com/keenondrums/cls-proxify): integration of pino and [CLS](https://github.com/jeff-lewis/cls-hooked). Useful for creating dynamically configured child loggers (e.g. with added trace ID) for each request.
|
75
|
+
+ [`crawlee-pino`](https://github.com/imyelo/crawlee-pino): use Pino to log within Crawlee
|
76
|
+
+ [`pino-colada`](https://github.com/lrlna/pino-colada): cute ndjson formatter for pino.
|
77
|
+
+ [`pino-dev`](https://github.com/dnjstrom/pino-dev): simple prettifier for pino with built-in support for common ecosystem packages.
|
78
|
+
+ [`pino-fluentd`](https://github.com/davidedantonio/pino-fluentd): send Pino logs to Elasticsearch,
|
79
|
+
MongoDB, and many [others](https://www.fluentd.org/dataoutputs) via Fluentd.
|
80
|
+
+ [`pino-lambda`](https://github.com/FormidableLabs/pino-lambda): log transport for cloudwatch support inside aws-lambda
|
81
|
+
+ [`pino-pretty-min`](https://github.com/unjello/pino-pretty-min): a minimal
|
82
|
+
prettifier inspired by the [logrus](https://github.com/sirupsen/logrus) logger.
|
83
|
+
+ [`pino-rotating-file`](https://github.com/homeaway/pino-rotating-file): a hapi-pino log transport for splitting logs into separate, automatically rotating files.
|
84
|
+
+ [`pino-tiny`](https://github.com/holmok/pino-tiny): a tiny (and extensible?) little log formatter for pino.
|