@withbuddi/buddi 0.1.0-pre.37 → 0.1.0-pre.39

package/node_modules/pino/docs/api.md

@@ -137,19 +137,13 @@ logger.info('hello') // Will throw an error saying info is not found in logger o
 
 Default: `5`
 
-Maximum nesting depth used by Pino's fallback serializer.
+Option to limit stringification at a specific nesting depth when logging circular objects.
 
 #### `edgeLimit` (Number)
 
 Default: `100`
 
-Maximum number of properties/elements per object or array used by Pino's fallback serializer.
-
-Pino uses the fallback serializer, and therefore applies `depthLimit` and `edgeLimit`, only after
-`JSON.stringify` throws. These options are not general limits on serialization work or output size.
-For example, `JSON.stringify` successfully serializes a non-circular object graph that contains
-repeated references to the same object. In that case, every reference is traversed and serialized
-in full, without applying either limit.
+Option to limit stringification of properties/elements when logging a specific object/array with circular references.
 
 <a id="opt-mixin"></a>
 #### `mixin` (Function):
@@ -417,7 +411,7 @@ Changes the shape of the log level. The default shape is `{ level: number }`.
 The function takes two arguments, the label of the level (e.g. `'info'`)
 and the numeric value (e.g. `30`).
 
-When using multiple transport targets, the log record must keep a numeric `level` field for per-target routing. Because of that, `formatters.level` cannot be used to replace `level` with a string or rename it in multi-target mode. `timestamp` customization is still supported.
+ps: The log level cannot be customized when using multiple transports
 
 ```js
 const formatters = {
@@ -471,13 +465,6 @@ in the serializers. The only exception is the `err` serializer as it is also app
 the object is an instance of `Error`, e.g. `logger.info(new Error('kaboom'))`.
 See `errorKey` option to change `err` namespace.
 
-Serializers are also applied to the [bindings passed to `logger.child()`](#logger-child-bindings).
-Child bindings are serialized once, when the child logger is created, so a matching
-serializer runs at that point rather than on every subsequent log call. This is
-deliberate: it allows a child logger to precompute its bindings and stay fast at log
-time. If a serializer needs to run per log call, pass the value to the log method
-instead of to `child()`.
-
 * See [pino.stdSerializers](#pino-stdserializers)
 
 #### `msgPrefix` (String)
@@ -737,25 +724,6 @@ logger.info({MIX: {IN: true}})
 // {"level":30,"time":1531254555820,"pid":55956,"hostname":"x","MIX":{"IN":true}}
 ```
 
-Do not pass an externally supplied object directly as the `mergingObject`.
-Top-level keys are written at the root of the log line and can conflict with
-Pino fields such as `level`, `time`, or `msg`, as well as application or
-security fields. If untrusted data must be logged, place it under an
-application-controlled key:
-
-```js
-// Avoid: user-controlled keys become top-level log fields
-logger.info(untrustedObject)
-
-// Prefer: user-controlled keys are contained under a trusted namespace
-logger.info({ untrusted: untrustedObject })
-```
-
-As a matter of good security hygiene, prefer not to log untrusted data at all
-unless it is necessary. When it is necessary, sanitize and redact it first.
-The same top-level key guidance applies to [`logger.child()` bindings](#logger-child-bindings)
-and [`logger.setBindings()`](#logger-set-bindings).
-
 If the object is of type Error, it is wrapped in an object containing a property err (`{ err: mergingObject }`).
 This allows for a unified error handling flow.
 
@@ -958,24 +926,6 @@ child.info('child!')
 
 The `bindings` object may contain any key except for reserved configuration keys `level` and `serializers`.
 
-Do not pass externally supplied objects directly as child bindings. Binding keys
-are top-level log fields emitted on every log line from the child logger, so
-user-controlled keys can conflict with Pino fields such as `level`, `time`, or
-`msg`, as well as application or security fields. If untrusted data must be
-included in child bindings, place it under an application-controlled key:
-
-```js
-// Avoid: user-controlled keys become top-level fields on every child log line
-const child = logger.child(untrustedObject)
-
-// Prefer: user-controlled keys are contained under a trusted namespace
-const child = logger.child({ untrusted: untrustedObject })
-```
-
-As a matter of good security hygiene, prefer not to log untrusted data at all
-unless it is necessary. When it is necessary, sanitize and redact it first.
-See also [`mergingObject`](#mergingobject) and [`logger.setBindings()`](#logger-set-bindings).
-
 ##### `bindings.serializers` (Object) - DEPRECATED
 
 Use `options.serializers` instead.
@@ -1073,11 +1023,6 @@ Adds to the bindings of this logger instance.
 **Note:** Does not overwrite bindings. Can potentially result in duplicate keys in
 log lines.
 
-Do not pass externally supplied objects directly as bindings. Binding keys are
-top-level log fields and can conflict with Pino fields or application fields.
-If untrusted data must be added, place it under an application-controlled key,
-for example `logger.setBindings({ untrusted })`, and sanitize or redact it first.
-
 * See [`bindings` parameter in `logger.child`](#logger-child-bindings)
 
 <a id="flush"></a>
@@ -1097,14 +1042,8 @@ and safer logging at low demand periods.
 
 If there is a need to wait for the logs to be flushed, a callback should be used.
 
-**Note:** `logger.flush()` does not flush the output of `pino-pretty`. See
-[Flush Limitations with `pino-pretty`](/docs/asynchronous.md) for more details.
-
-**Note:** in the browser this method is a no-op and `cb` is never invoked. See
-[Node.js-only APIs](/docs/browser.md#nodejs-only-apis).
-
 * See [`destination` parameter](#destination)
-* See [Asynchronous Logging ⇗](./asynchronous.md)
+* See [Asynchronous Logging ⇗](/docs/asynchronous.md)
 
 <a id="logger-level"></a>
 ### `logger.level` (String) [Getter/Setter]
@@ -1200,10 +1139,6 @@ register its own serializer upon instantiation the serializers of the parent wil
 
 The logger instance is also an [`EventEmitter ⇗`](https://nodejs.org/dist/latest/docs/api/events.html#events_class_eventemitter)
 
-**Note:** the `EventEmitter` methods are no-ops in the browser, so this event
-never fires there. See
-[Node.js-only APIs](/docs/browser.md#nodejs-only-apis).
-
 A listener function can be attached to a logger via the `level-change` event
 
 The listener is passed five arguments:
@@ -1259,8 +1194,6 @@ Exposes the cumulative `msgPrefix` of the logger.
 Create a Pino Destination instance: a stream-like object with
 significantly more throughput than a standard Node.js stream.
 
-**Note:** this is not available in the browser build. See [Node.js-only APIs](/docs/browser.md#nodejs-only-apis).
-
 ```js
 const pino = require('pino')
 const logger = pino(pino.destination('./my-file'))
@@ -1295,8 +1228,6 @@ A `pino.destination` instance can also be used to reopen closed files
 Create a stream that routes logs to a worker thread that
 wraps around a [Pino Transport](/docs/transports.md).
 
-**Note:** this is not available in the browser build. See [Node.js-only APIs](/docs/browser.md#nodejs-only-apis).
-
 ```js
 const pino = require('pino')
 const transport = pino.transport({
@@ -1417,8 +1348,6 @@ Notes:
 Create a stream composed by multiple destination streams and returns an
 object implementing the [MultiStreamRes](#multistreamres) interface.
 
-**Note:** this is not available in the browser build. See [Node.js-only APIs](/docs/browser.md#nodejs-only-apis).
-
 ```js
 var fs = require('node:fs')
 var pino = require('pino')

package/node_modules/pino/docs/asynchronous.md

@@ -21,12 +21,9 @@ output stream as the messages are generated with a _blocking_ operation.
 
 ### AWS Lambda
 
-Asynchronous logging in AWS Lambda functions will tend to cause delayed
-or lost log messages, as logs may not be written to the destination
-before the runtime is frozen.
-
-For Lambda deployments, it's recommended to always use a destination
-with `sync: true`.
+Asynchronous logging is disabled by default on AWS Lambda or any other environment
+that modifies `process.stdout`. If forcefully turned on, we recommend calling `dest.flushSync()` at the end
+of each function execution to avoid losing data.
 
 ## Caveats
 
@@ -37,18 +34,6 @@ Asynchronous logging has a couple of important caveats:
 * There is a possibility of the most recently buffered log messages being lost
   in case of a system failure, e.g. a power cut.
 
-### Flush Limitations with `pino-pretty`
-
-`logger.flush()` does not flush the output of `pino-pretty` because:
-
-1. **Transport Architecture**: `pino-pretty` runs in a separate worker thread via the transport mechanism.
-
-2. **Cross-Thread Flush**: `logger.flush(cb)` does reach the worker. Since [thread-stream#198](https://github.com/pinojs/thread-stream/pull/198) the worker waits for the shared buffer to be drained, then looks for a flush primitive on the destination the transport returned: `flush`, `flushSync`, or a pending `drain`.
-
-3. **No Flush Primitive**: The stream `pino-pretty` returns exposes none of those. Its buffered `SonicBoom` is reachable only through the internal `pump`, so the worker has nothing to call and acknowledges the flush right away.
-
-This means that even with `logger.flush()`, your formatted logs may not appear immediately. The flush only guarantees that the main thread buffer was written and that the worker drained the shared buffer, not that `pino-pretty` has written its formatted output.
-
 See also:
 
 * [`pino.destination` API](/docs/api.md#pino-destination)

package/node_modules/pino/docs/browser.md

@@ -7,69 +7,6 @@ This can be useful with isomorphic/universal JavaScript code.
 By default, in the browser,
 `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.
 
-<a id="nodejs-only-apis"></a>
-## Node.js-only APIs
-
-The browser build (`browser.js`, selected through the `browser` field in
-`package.json`) does not implement the parts of the API that depend on the file
-system or on worker threads. Accessing them in the browser throws a
-`TypeError`, because the export is simply absent:
-
-```js
-const pino = require('pino')
-pino.destination('./my-file') // TypeError: pino.destination is not a function
-```
-
-The following statics are available in Node.js only:
-
-| Static | Why it is Node.js only |
-| --- | --- |
-| [`pino.destination()`](/docs/api.md#pino-destination) | Returns a [`SonicBoom`](https://github.com/pinojs/sonic-boom) instance writing to a file descriptor. |
-| [`pino.transport()`](/docs/api.md#pino-transport) | Runs a [transport](/docs/transports.md) on a worker thread. |
-| [`pino.multistream()`](/docs/api.md#pino-multistream) | Fans out to multiple destination streams. |
-
-`pino.levels`, `pino.stdSerializers` and `pino.stdTimeFunctions` are available in
-both environments.
-
-### Methods that are no-ops in the browser
-
-These exist on a browser logger, so calling them is safe, but they do nothing:
-
-* [`logger.flush([cb])`](/docs/api.md#flush) — there is no write buffer
-  to flush. Note that a callback passed to it is **not** invoked.
-* Every `EventEmitter` method (`on`, `once`, `emit`, `removeListener`,
-  `listeners`, ...). As a consequence the
-  [`level-change`](/docs/api.md#level-change) event never fires in the
-  browser.
-
-### Writing isomorphic code
-
-Code shared between a server and a browser bundle should not call the Node.js
-only statics unconditionally. Guard the call rather than the environment, so the
-same branch works under any bundler:
-
-```js
-const pino = require('pino')
-
-const logger = pino.destination
-  ? pino(pino.destination('./my-file')) // Node.js
-  : pino({ browser: { asObject: true } }) // browser
-```
-
-Note that the browser build's `pino()` accepts the options object only. A second
-`destination` argument is accepted but ignored, so a logger constructed with one
-still writes to the console rather than failing:
-
-```js
-// in the browser the second argument is ignored, not honoured
-const logger = pino({ level: 'info' }, someDestination)
-logger.info('still goes to the console')
-```
-
-Assigning a no-op shim onto the `pino` export (`pino.destination = () => {}`)
-works too, but it mutates a module object shared with every other importer in the
-bundle; guarding the call site keeps the change local.
-
 ## Options
 
 Pino can be passed a `browser` object in the options object,

package/node_modules/pino/docs/child-loggers.md

@@ -20,26 +20,6 @@ module.exports = {
 }
 ```
 
-Child logger bindings are top-level fields on every log line emitted by the
-child logger. Do not create child loggers from externally supplied objects or
-user-controlled binding names, because those keys can conflict with Pino fields
-such as `level`, `time`, or `msg`, as well as application or security fields.
-If untrusted data must be associated with logs, place it under an
-application-controlled key:
-
-```js
-// Avoid: user-controlled keys become top-level fields on every child log line
-const child = logger.child(untrustedObject)
-
-// Prefer: user-controlled keys are contained under a trusted namespace
-const child = logger.child({ untrusted: untrustedObject })
-```
-
-As a matter of good security hygiene, prefer not to log untrusted data at all
-unless it is necessary. When it is necessary, sanitize and redact it first.
-See also [`logger.child()` in the API documentation](/docs/api.md#child) and
-[`mergingObject`](/docs/api.md#mergingobject).
-
 ## Cost of child logging
 
 Child logger creation is fast:
@@ -108,8 +88,7 @@ behavior.
 
 There may be cases where this edge case becomes problematic if a JSON parser with alternative behavior
 is used to process the logs. It's recommended to be conscious of namespace conflicts with child loggers,
-in light of an expected log processing approach. This is especially important for untrusted data: do not
-allow externally supplied objects or user-controlled key names to become child logger bindings.
+in light of an expected log processing approach.
 
 One of Pino's performance tricks is to avoid building objects and stringifying
 them, so we're building strings instead. This is why duplicate keys between

package/node_modules/pino/docs/ecosystem.md

@@ -71,7 +71,6 @@ according to a given format string.
 
 + [`@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)
 + [`@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/)
-+ [`@sentry/node`](https://docs.sentry.io/platforms/javascript/guides/node/configuration/integrations/pino/): Sentry SDK with native pinoIntegration for direct Pino instrumentation and error tracking.
 + [`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).
 + [`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.
 + [`crawlee-pino`](https://github.com/imyelo/crawlee-pino): use Pino to log within Crawlee

package/node_modules/pino/docs/help.md

@@ -147,19 +147,11 @@ const logger = pino({
 <a id="dupe-keys"></a>
 ## How Pino handles duplicate keys
 
-Duplicate keys are possible when a logged object contains a top-level key that
-collides with a Pino field or a key in the child logger's bindings, or when child
-logger bindings collide with parent bindings.
-
-For untrusted data, avoid passing externally supplied objects directly to logging
-methods or child logger bindings. User-controlled top-level keys can conflict
-with Pino fields such as `level`, `time`, or `msg`, as well as application or
-security fields. If untrusted data must be logged, place it under an
-application-controlled key, such as `logger.info({ untrusted })`, and prefer not
-to log untrusted data at all unless necessary.
+Duplicate keys are possibly when a child logger logs an object with a key that
+collides with a key in the child loggers bindings.
 
 See the [child logger duplicate keys caveat](/docs/child-loggers.md#duplicate-keys-caveat)
-and [`logger.child()` bindings](/docs/api.md#logger-child-bindings) for more information.
+for information on this is handled.
 
 <a id="level-string"></a>
 ## Log levels as labels instead of numbers

package/node_modules/pino/docs/lts.md

@@ -37,35 +37,6 @@ A "month" is defined as 30 consecutive days.
 
 [semver]: https://semver.org/
 
-<a name="supported-nodejs"></a>
-
-### Supported Node.js versions
-
-Pino follows the [Node.js release schedule][node-release]. A Pino release line
-is tested against, and supports, every Node.js release line that is in its
-_current_, _active LTS_, or _maintenance LTS_ phase when the Pino line is
-released, as described above.
-
-Support for a Node.js version is **only dropped in a new Pino major release**. A
-published Pino major will never drop a Node.js release line that it originally
-shipped with, so upgrading within a major line (for example, from `9.1.0` to
-`9.4.0`) will never remove support for a Node.js version you already run on.
-
-Once a Node.js release line reaches its end-of-life, Pino supports it on a
-best-effort basis, with the following caveats:
-
-- End-of-life Node.js versions are not exercised in continuous integration.
-- Some fixes and features cannot be backported to the Pino lines that still
-  support them.
-- Dependencies cannot be kept up to date.
-
-To keep running on an end-of-life Node.js version, pin your dependency to the
-last Pino major line that supported it. The [Schedule](#lts-schedule) below maps
-each Pino release line to the Node.js versions it supports; for example, to stay
-on Node.js 14, install the latest `8.x` release with `"pino": "8.x"`.
-
-[node-release]: https://github.com/nodejs/release#release-schedule
-
 <a name="lts-schedule"></a>
 
 ### Schedule

package/node_modules/pino/docs/pretty.md

@@ -32,7 +32,4 @@ module like [`pino-pretty`][pp]:
   logger.info('hi')
   ```
 
-**Note:** `logger.flush()` does not flush the output of `pino-pretty`. See
-[Flush Limitations with `pino-pretty`](/docs/asynchronous.md) for more details.
-
   [pp]: https://github.com/pinojs/pino-pretty

package/node_modules/pino/docs/redaction.md

@@ -1,11 +1,14 @@
 # Redaction
 
+> Redaction is not supported in the browser [#670](https://github.com/pinojs/pino/issues/670)
+
 To redact sensitive information, supply paths to keys that hold sensitive data
 using the `redact` option. Note that paths that contain hyphens need to use
 brackets to access the hyphenated property:
 
 ```js
-const logger = require('.')({\n  redact: ['key', 'path.to.key', 'stuff.thats[*].secret', 'path["with-hyphen"]']
+const logger = require('.')({
+  redact: ['key', 'path.to.key', 'stuff.thats[*].secret', 'path["with-hyphen"]']
 })
 
 logger.info({
@@ -34,7 +37,8 @@ an object. This allows control over *how* information is redacted.
 For instance, setting the censor:
 
 ```js
-const logger = require('.')({\n  redact: {
+const logger = require('.')({
+  redact: {
     paths: ['key', 'path.to.key', 'stuff.thats[*].secret'],
     censor: '**GDPR COMPLIANT**'
   }
@@ -63,7 +67,8 @@ This will output:
 The `redact.remove` option also allows for the key and value to be removed from output:
 
 ```js
-const logger = require('.')({\n  redact: {
+const logger = require('.')({
+  redact: {
     paths: ['key', 'path.to.key', 'stuff.thats[*].secret'],
     remove: true
   }

package/node_modules/pino/docs/transports.md

@@ -159,36 +159,6 @@ const transport = pino.transport({
 pino(transport)
 ```
 
-#### `formatters.level` with multiple targets
-
-When using `targets`, Pino routes records in the worker thread based on the numeric `level` field in each log line. Because of that, a custom `formatters.level` must not remove, rename, or convert `level` to a string when multiple targets are configured.
-
-Unsupported example:
-
-```js
-const logger = pino({
-  formatters: {
-    level (label) {
-      return { severity: label }
-    }
-  },
-  transport: {
-    targets: [
-      { target: 'pino/file', options: { destination: 1 } },
-      { target: 'pino/file', options: { destination: 2 } }
-    ]
-  }
-})
-```
-
-In this case, Pino cannot apply per-target level filtering correctly. Depending on how the transport is constructed, Pino will either throw or emit a warning.
-
-Supported alternatives:
-
-- Keep the numeric `level` field unchanged when using multiple targets.
-- If you need string labels such as `"info"`, transform the output in a transport pipeline or in a custom transport after routing has already happened.
-- `timestamp` customization still works with multiple targets.
-
 It is also possible to use the `dedupe` option to send logs only to the stream with the higher level.
 ```js
 const pino = require('pino')
@@ -584,7 +554,6 @@ PRs to this document are welcome for any new transports!
 + [pino-roll](#pino-roll)
 + [pino-seq-transport](#pino-seq-transport)
 + [pino-sentry-transport](#pino-sentry-transport)
-+ [Sentry Native SDK Integration](#sentry-native-integration)
 + [pino-slack-webhook](#pino-slack-webhook)
 + [pino-telegram-webhook](#pino-telegram-webhook)
 + [pino-yc-transport](#pino-yc-transport)
@@ -1199,46 +1168,6 @@ pino(transport)
 [pino-sentry-transport]: https://github.com/tomer-yechiel/pino-sentry-transport
 [Sentry]: https://sentry.io/
 
-<a id="sentry-native-integration"></a>
-### Sentry Native SDK Integration
-
-As an alternative to using a Pino transport, Sentry's Node.js SDK (v10.18.0+) provides a native `pinoIntegration` that instruments Pino directly. This approach captures logs within the Sentry SDK rather than forwarding them through a separate worker process.
-
-```js
-const Sentry = require('@sentry/node')
-const pino = require('pino')
-
-Sentry.init({
-  dsn: 'https://******@sentry.io/12345',
-  enableLogs: true,
-  integrations: [Sentry.pinoIntegration()],
-})
-
-const logger = pino()
-logger.info('This log will be captured by Sentry')
-```
-
-The integration supports configuring which log levels are captured as Sentry logs or errors:
-
-```js
-Sentry.init({
-  dsn: 'https://******@sentry.io/12345',
-  enableLogs: true,
-  integrations: [
-    Sentry.pinoIntegration({
-      // Capture these levels as Sentry logs
-      log: { levels: ['info', 'warn', 'error'] },
-      // Capture these levels as Sentry errors
-      error: { levels: ['error', 'fatal'], handled: true }
-    })
-  ],
-})
-```
-
-**Note:** This integration only works in the Node.js runtime. Requires Sentry SDK version 10.18.0 or higher and pino version 8.0.0 or higher. For full documentation, see the [Sentry Pino integration docs][sentry-pino-docs].
-
-[sentry-pino-docs]: https://docs.sentry.io/platforms/javascript/guides/node/configuration/integrations/pino/
-
 <a id="pino-seq"></a>
 ### pino-seq
 

package/node_modules/pino/docs/web.md

@@ -274,25 +274,28 @@ See the [pino-http README](https://npm.im/pino-http) for more info.
 ## Pino with Hono
 
 ```sh
-npm install pino @hono/structured-logger hono
+npm install pino pino-http hono
 ```
 
 ```js
 import { serve } from '@hono/node-server';
 import { Hono } from 'hono';
 import { requestId } from 'hono/request-id';
-import { structuredLogger } from '@hono/structured-logger';
-import pino from 'pino';
-
-const rootLogger = pino();
+import { pinoHttp } from 'pino-http';
 
 const app = new Hono();
 app.use(requestId());
-app.use(
-  structuredLogger({
-    createLogger: (c) => rootLogger.child({ requestId: c.var.requestId }),
-  })
-);
+app.use(async (c, next) => {
+  // pass hono's request-id to pino-http
+  c.env.incoming.id = c.var.requestId;
+
+  // map express style middleware to hono
+  await new Promise((resolve) => pinoHttp()(c.env.incoming, c.env.outgoing, () => resolve()));
+
+  c.set('logger', c.env.incoming.log);
+
+  await next();
+});
 
 app.get('/', (c) => {
   c.var.logger.info('something');
@@ -303,4 +306,4 @@ app.get('/', (c) => {
 serve(app);
 ```
 
-See the [@hono/structured-logger README](https://github.com/honojs/middleware/blob/main/packages/structured-logger/README.md) for more info.
+See the [pino-http README](https://npm.im/pino-http) for more info.

package/node_modules/pino/eslint.config.js

@@ -8,29 +8,21 @@ module.exports = defineConfig([
     ts: true
   }),
   globalIgnores([
+    'pino.d.ts',
     'test/fixtures/syntax-error-esm.mjs',
-    'test/fixtures/ts/*cjs'
+    'test/fixtures/ts/*cjs',
   ]),
   {
     rules: {
-      'comma-dangle': ['error', 'never'],
-      'no-var': 'off'
-    }
-  },
-  {
-    files: ['pino.d.ts'],
-    rules: {
-      '@typescript-eslint/no-use-before-define': 'off',
-      '@typescript-eslint/no-unused-vars': 'off'
-    }
+      'no-var': 'off',
+    },
   },
   {
     files: ['test/types/**/*'],
     rules: {
-      'no-unused-expressions': 'off',
       '@typescript-eslint/no-unused-expressions': 'off',
       '@typescript-eslint/no-unused-vars': 'off',
-      'n/handle-callback-err': 'off'
-    }
-  }
+      'n/handle-callback-err': 'off',
+    },
+  },
 ])

package/node_modules/pino/lib/caller.js

@@ -1,20 +1,10 @@
 'use strict'
 
-const util = require('node:util')
-
-// getCallSite requires Node >=22.9.0
-// getCallSite was renamed in Node 23.3.0 / 22.12.0
-const getCallSites = util.getCallSites ?? util.getCallSite
-
 function noOpPrepareStackTrace (_, stack) {
   return stack
 }
 
 module.exports = function getCallers () {
-  if (getCallSites) {
-    return getCallSites().slice(2).map(callSite => callSite.scriptName)
-  }
-
   const originalPrepare = Error.prepareStackTrace
   Error.prepareStackTrace = noOpPrepareStackTrace
   const stack = new Error().stack

package/node_modules/pino/lib/meta.js

@@ -1,3 +1,3 @@
 'use strict'
 
-module.exports = { version: '10.4.0' }
+module.exports = { version: '10.3.1' }