I don't know what this TypeScript stuff is trying to do, but we shouldn't have to pin the pino dependency and extra features of Pino shouldn't ever break anything here. Fastify is quite clear what it expects a logger to minimally look like. That doesn't mean any logger that meets that minimum requirement can't have its own feature set.

well then it should also be fixed on pino's side right? AFAIU pino made a breaking type change?

I don't know what this TypeScript stuff is trying to do, but we shouldn't have to pin the pino dependency and extra features of Pino shouldn't ever break anything here. Fastify is quite clear what it expects a logger to minimally look like. That doesn't mean any logger that meets that minimum requirement can't have its own feature set.

well then it should also be fixed on pino's side right? AFAIU pino made a breaking type change?

A feature was added to Pino that allows the user to retrieve the configured "message prefix" for the current logger instance (root, child, etc). See pinojs/pino@4605454. This is not a breaking change. It is a new feature that has no bearing any of the logger methods (.info, etc) nor on the .child method. It is a completely transparent addition to anyone utilizing Pino according to the minimally required interface of Fastify:

I see, thanks for the explanation

Well, I think the problem is here:

        /**
         * Get `msgPrefix` of the logger instance.
         *
         * See {@link https://github.com/pinojs/pino/blob/main/docs/api.md#msgprefix-string}.
         */
        get msgPrefix(): string | undefined;

It should be something like:

        /**
         * Get `msgPrefix` of the logger instance.
         *
         * See {@link https://github.com/pinojs/pino/blob/main/docs/api.md#msgprefix-string}.
         */
        readonly msgPrefix?: string;

But we lose the getter specification

The type change is breaking (in the sense that it breaks our tests)

We can either do this PR or change the type definition, I'm fine with either

Here is the PR to update the type definition #6287. I can close out this PR if that is the approach we want to take