chore(deps): upgrade @types/pino to be compatible with latest sonic-stream types

[legendecas]

Which problem is this PR solving?

• @opentelemetry/instrumentation-pino failed to compile #591

Short description of the changes

• upgrade @types/pino to 6.3.11

[Flarna]

Does this still work for users using an older version of @types/pino?

A while ago we had a discussion if we should pin the version here or not. Or even use * to accept any version selected in the final app.

[codecov]

Codecov Report

Merging #592 (b3c97d4) into main (68e5449) will not change coverage.
The diff coverage is n/a.

❗ Current head b3c97d4 differs from pull request most recent head 80a20b8. Consider uploading reports for the commit 80a20b8 to get more accurate results

@@           Coverage Diff           @@
##             main     #592   +/-   ##
=======================================
  Coverage   94.78%   94.78%           
=======================================
  Files         179      179           
  Lines       10976    10976           
  Branches     1088     1088           
=======================================
  Hits        10404    10404           
  Misses        572      572           

[legendecas]

@Flarna Does this still work for users using an older version of @types/pino?

IIUC, types maintained in DefinitelyTyped versioned with the same minor.patch following the original package (see https://github.com/DefinitelyTyped/DefinitelyTyped#how-do-definitely-typed-package-versions-relate-to-versions-of-the-corresponding-library). If there are no mistakes, the version of type packages should follow semantic versioning.

I'm not sure which condition you are referring to. If you mean users that declared their own @types/pino dependencies in their package, as long as the user-defined version range is compatible with the version defined in @opentelemetry/instrumentation-pino, it should be fine.

[legendecas]

Or even use * to accept any version selected in the final app.

IIUC, the instrumentation package should set a version range of pino that it supports (like say, declare a set of version range in peer dependencies). A * sounds not great to me.

[Flarna]

@types packages follow major.minor of their original. They may add/remove/rework definitions during this resulting in breakage like here. So in short @types packages don't follow semver (and this is documented at DefinitelyTyped).

I'm not sure which condition you are referring to. If you mean users that declared their own @types/pino dependencies in their package, as long as the user-defined version range is compatible with the version defined in @opentelemetry/instrumentation-pino, it should be fine.

I mean the version selected by the end user. @opentelemetry/instrumentation-pino uses a fixed version therefore a mismatch is likely. In that case NPM installs both versions (one as child of @opentelemetry/instrumentation-pino and one in the root node_modules folder).

[dyladan]

Merging this since it is fixing the build which breaks in every PR