Update dependency @elastic/ecs-winston-format to v1.5.3

[renovate]

This PR contains the following updates:

Package	Change	Age	Adoption	Passing	Confidence
@elastic/ecs-winston-format (source)	1.3.1 -> 1.5.3

---

Warning

Some dependencies could not be looked up. Check the Dependency Dashboard for more information.

---

Release Notes

elastic/ecs-logging-nodejs (@​elastic/ecs-winston-format)

v1.5.3

Compare Source

• Fix format handling for the log record emitted by Winston for
  unhandledRejection events (when configured to handle them) as of
  winston@3.12.0. In that version the log record changed slightly to
  set record.rejection rather than record.exception.

v1.5.2

Compare Source

• Fix the Winston transformers to not delete the level property from the
  info object, because https://github.com/winstonjs/logform#info-objects says
  "Every info must have at least the level and message properties".
  https://github.com/elastic/ecs-logging-nodejs/issues/173/173)

v1.5.0

Compare Source

• Add ecsFields and ecsStringify exports that are winston formatters
  that separate the gathering of ECS fields (ecsFields) and the
  stringification of a log record to an ecs-logging JSON object
  (ecsStringify). This allows for better composability using
  winston.format.combine.

  The preferred way to import now changes to:

  const { ecsFormat } = require('@​elastic/ecs-winston-format'); // CommonJS
  import { ecsFormat } from '@​elastic/ecs-winston-format'; // ESM

  The old way will be deprecated and removed in the future:

  const ecsFormat = require('@​elastic/ecs-winston-format'); // OLD

  Typical usage of ecsFormat is unchanged:

  const { ecsFormat } = require('@​elastic/ecs-winston-format');
  const log = winston.createLogger({
      format: ecsFormat(/* options */),
      // ...

  However, one can now use the separated formatters as follows:

  const { ecsFields, ecsStringify } = require('@​elastic/ecs-winston-format');
  const log = winston.createLogger({
      format: winston.format.combine(
          ecsFields(/* options */),
          // Add any custom formatters, e.g. one to redact added ECS fields.
          ecsStringify()
      ),
      // ...

  One good use case is for redaction of sensitive fields in the log record
  ashttps://github.com/elastic/ecs-logging-nodejs/issues/57s/57. See a
  complete example at examples/redact-fields.js.

• Fix/improve serialization of error details to error.* fields for the
  various ways a Winston logger handles Error instances.

  const aCause = new Error('the cause');
  const anErr = new Error('boom', {cause: aCause});
  anErr.code = 42;
  
  log.debug("some message", anErr); // Form 1
  log.info(anErr, {foo: "bar"}); // Form 2
  log.warn("some message", {err: anErr, foo: "bar"}); // Form 3

  1. Winston will add a stack field for an error passed this way.
  2. If the logform.errors(...) format is configured, Winston will serialize
     anErr passed this way.
  3. Passing an error via the err meta field is specific to
     @elastic/ecs-winston-format and is discouraged. If possible, use style 1.
     It will remain for now for backward compatibility.

  With this change, all three cases above will result in anErr details being
  serialized to ECS error.* fields,
  as well as error.cause
  and other properties on the error instance. Forms 2 and 3 are enabled via
  the convertErr: true configuration option.
  See examples/basic.js.

  In addition, if your Winston logger is configured to handle uncaughtException
  and/or unhandledRejection (https://github.com/winstonjs/winston#exceptions),
  then the Error instance included in this log record will be serialized to
  error.* fields. See test/uncaught-exception.js
  and test/unhandled-rejection.js for examples.
  https://github.com/elastic/ecs-logging-nodejs/issues/128/128)

• Switch to safe-stable-stringify for JSON serialization. This library
  protects against circular references and biginthttps://github.com/elastic/ecs-logging-nodejs/pull/155pull/155)

• Explicitly depend on triple-beam (>=1.1.0 when MESSAGE was added).
  Before this change, this package was assuming that it would be installed by
  the user. This worked for npm's flat install -- npm install winston will
  install a node_modules/triple-beam/... -- but not for Yarn 2's PnP install
  mechanishttps://github.com/elastic/ecs-logging-nodejs/issues/108sues/108)

• Set http.request.id field (see ecs-helpers CHANGELOG).

• Add support for default import in TypeScript, with or without the
  esModuleInterop setting:

  import ecsFormat from '@​elastic/ecs-pino-format';

  However, note that using named imports is now preferred.

v1.4.0

• Add service.version, service.environment, and service.node.name log
  correlation fields, automatically inferred from an active APM agent. As
  well, the following ecsFormat configuration options have been added for
  overriding these and existing correlation fields: serviceName,
  serviceVersion, serviceEnvironment, serviceNodeName.
  https://github.com/elastic/apm-agent-nodejs/issues/319531https://github.com/elastic/ecs-logging-nodejs/issues/121suhttps://github.com/elastic/ecs-logging-nodejs/issues/87js/issues/87)

• Change to adding dotted field names ("ecs.version": "1.6.0"), rather than
  namespaced fields ("ecs": {"version": "1.6.0"}) for most fields. This is
  supported by the ecs-logging spec, and arguably preferred in the ECS logging
  docs. It is also what the ecs-logging-java libraries do. The resulting output
  is slightly shorter, and accidental collisions with user fields is less
  likely.

• Stop adding ".log" suffix to event.dataset field.
  (#​95)

---

Configuration

📅 Schedule: Branch creation - At any time (no schedule defined), Automerge - At any time (no schedule defined).

🚦 Automerge: Disabled by config. Please merge this manually once you are satisfied.

♻ Rebasing: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox.

🔕 Ignore: Close this PR and you won't be reminded about this update again.

---

• If you want to rebase/retry this PR, check this box

---

This PR was generated by Mend Renovate. View the repository job log.