Please use ErrorConstructor if you really means to be a constructor.

new () => Error is a subset of ErrorConstructor and provides all the functionality required by createError().
It doesn't seem necessary to also require that these classes are also callable as functions.

I'd like to be able to use this with classes that inherit from Error, which aren't callable as functions like ErrorConstructor requires.
eg.
class MyError extends Error {}

I'm having difficulty following the reasoning for this PR, but it sounds like a misunderstanding of Error. The implementation here follows the specification:

https://262.ecma-international.org/13.0/#sec-error-objects

creates and initializes a new Error object when called as a function rather than as a constructor. Thus the function call Error(…) is equivalent to the object creation expression new Error(…) with the same arguments.

@jsumners The value Error has the type ErrorConstructor, you can call Error as a function eg. Error("some string") or using new Error("some string") and you''ll get a value of type Error.

The current types defined for createError only allow you to pass a value of type Error as the Base parameter, but the function only works if you pass a value of ErrorConstructor. In fact ,the default value assigned to Base is Error which has the type ErrorConstructor.

This PR makes it possible to call createError('CODE', 'hey %s', 500, Error) from Typescript, without this change you can only call createError('CODE', 'hey %s', 500, Error("some string")) which results in a runtime error.

Without this change it's not possible to call createError() correctly from Typescript.

ping: @fastify/typescript

The finding is correct, it should not be Error.

We have this issue also in fastify

I would prefer ErrorConstructor. If you are using typescript wouldnt you use a class anyway?

ErrorConstructor is a proper Error structure for JavaScript.
And it also required to provide the function creation method.

interface ErrorConstructor {
    new(message?: string): Error;
    (message?: string): Error;
    readonly prototype: Error;
}

But, I still in favor of using ErrorConstructor as it is more predictable in the structure and follow the spec.

As @Uzlopak said, this is a TS definition issue. Thanks for finding and fixing it, @jessta!
I agree with @climba03003, and I would prefer ErrorConstructor to be used here since it is more flexible and usable by Object.create(.
@jessta I am trying to understand why you would prefer to have only a strict constructor here.

I've updated the types to be ErrorConstructor since that seems to be the consensus.