interface SomeProperties {
   requiredProperty1: string;
   requiredProperty2: number;
}

function serialize<T extends SomeProperties>(x: T): string {
//                 ~~~~~~~~~~~~~~~~~~~~~~~~
    return JSON.stringify(x);
}

The obvious fix would be to replace the generic with its constraint, like so

function serialize(x: SomeProperties): string {
    return JSON.stringify(x);
}

However, this is a (slightly) breaking change for consumers! (affecting the type system only, not runtime behavior)

Before the change, this usage is just fine:

serialize({ 
   requiredProperty1: 'foo',
   requiredProperty2: 123,
   excessProperty: 'no problem'
});

But afterwards, we get a TS error that excessProperty does not exist on type SomeProperties (this happens specifically because we're supplying an object literal as the argument; a variable won't trigger this check). And, often, that's the right behavior! There is usually no need for excess properties.

But, sometimes (as, possibly, in the example given here), we actually did want to allow excess properties, and perhaps that's even why the original author wrote the function that way.

In order to preserve that behavior, the fix is to reflect reasonable excess properties in the index signature of SomeProperties. Changing it to

interface SomeProperties {
   requiredProperty1: string;
   requiredProperty2: number;
   [anyOtherProperties: string | number | symbol]: unknown;
}

we get our original, permissive behavior back.

Deciding whether to fix the function signature type or the call sites is a case-by-case matter.