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.
@@ -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
+
@@ -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`.
@@ -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.