Возможно тебе нужно что-то типа mixin'ов как во Vue, и миксен тебе вернёт класс вкотором будут твои реализации, типа такого
https://mariusschulz.com/blog/mixin-classes-in-typescript#:~:text=Mixins%20in%20JavaScript%2FTypeScript,is%20based%20on%20composing%20behavior.

спасибо большое, но ведь при таких раскладах прийдется писать реализацию методов у каждого класса, который использует эти интерфейсы. Я делаю сейчас так: допустим есть на беке user-controller с методами get, post, put, delete. В базовом классе CrudRequester у меня все эти методы реализованы, мне остается сделать так:

export const userController = new CrudRequester('/api/users')

В userController у меня уже будут все методы

Если появятся новые эндпоинты в user-controller на беке, я могу сделать так

class UserController extends CrudRequester {
  someOtherMethod() {...}
}
export const userController = new UserController('/api/users')

Если делать с разбитием на 4 интерфейса код будет таким

interface IUserController extends GetRequest, PutRequest, PostRequest, DeleteRequest

class UserController implements IUserController {
    constructor(private url: string) {};
    get() {...}
    post() {... }
    put() {... }
    delete() {...}
}

И так для каждого контроллера (эндпоинта) на беке, а у меня их очень много. Получается много повторений или я туплю?

имхо для класов где не нужны все методы лучше использовать композицию и facade шаблон вместо наследования
вот пример с контролером где есть только get и под капотом используется CrudRequester
https://www.typescriptlang.org/play/index.html#code/MYGwhgzhAEDCBOBXAJgJQKYEdHogF3XmgG8BYAKGiumAHsA7fJYPW+ACgAd4BLANzAFoieCABc0Jj3oBzAJQkAvgG4K1aDPR52CspXXV4WkfWh4AFjwgA6ESGXQ11RU6qda+HSVcGjeE2aWNnaq+lQuYdCciNq6Pup+ARZWtqKh6hHqyOggWuheegaGxvCmycFpPhERFKCQMADy9CAAngDiWrAMePC0ILlExI6RRti4BPASCCgYY-iEoT50jD2ILGzsdhJSsnGR6uXWozjzRAC80PToAO5wSGhYJxObonJVFD6asd77xf6lgRSx3GhGsXx06WcFAiQA

Спасибо, в итоге пока остановился на миксинах из подсказки @valburyakov (бесконечные благодарности), по сути это композиция и получается как надо- удобно оборачивать, тс показывает все как надо, можно расширять методами конечные классы с api. Есть пара неудобных моментов, особенно со статическим свойством, буду думать как улучшить.
https://www.typescriptlang.org/play/index.html?ssl=1&ssc=1&pln=47&pc=1#code/C4TwDgpgBAwg9gOwM7AE4FcDGw6oDwAqUAvFAN4C+AfCVAhAO5QAUAdOwIaoDmSAXFA4IQAbQC6AShI0CAbgCwAKCWhIUAEoQAjuggoAyhGDAAlgl60ySqDajpUAGwEpUZ7kopKlAM3QJsJohQAOomwAAWAOJGhABCHEjQEAAewBAIACZIsIguWDioUABkGtq6Bkam5khUzPGJAgT1EFJWirZQqEb2CFCYDgnZKWmZ2c3k1h223EbMrZ3dqL3NrPYOUJ7tGwqKmz5+AUGhEQAKcChxCUmp6Vk5yGj5uMWlOnrAhsZuNXVXjc2tSY2LrAHp9AZIIY3UZQcZtKa2MDnYBzcgLUFLWFXVaODaTCg7PaKXz+UxHMLhE4cYCYcKXRJQYa3bLwB4YbDPEqaN4VL7VWrNf5XQFbYGLXr9QaM6F3OFAqZgam05gmDLONBueYgsErNZQADUUAA5AB6I0GqCqzY2AkeLzEg5k3rHcIAEQgDiMEHp1xGd1ZeQ5hS5ZXenyqvAFfygTWFE1F6LBksh0r9Yyu8YRNgyHq9KrVUBcmrR2sxutxhtN5sNVvxhPtyeyAFVEqgAIJgEyZ2woakmTB2XGkI0cTsm9CtpBGu3KRSNqD6OAAWwgHa78J7wD7A71w9HJhNSGXEFuSLMwGnuwbuWAUBbEFQrLQcAcnsKpBd0RRLrOKGYP6VcJ-wpd1PTSZh73bTsJBgiQdkwG8F2PNcn1QF831oT9ZkXFc1zg68HjsVtUPQh9aHoJhIJI18HzmeDEKPXDO2ojDSAopCmJMFjaIkAij09VgHDgbhmAnB9uNQVhFRpICjQARgAJgAZiNGClAQ5AXwgQThOYRjV2YxBnxoySZhRGCdiAA

Рад, что вам подошло. Но хочу сказать, что не стоит злоупотреблять таким подходом, иначе потом могут быть проблемы с поддержкой и расширяемостью всего этого. Как и во Vue миксины опасная вещь, и нужно использовать только там где действительно необходимо.

Да, минусы однозначно есть
Не нравится, что приходится так дженерик прописывать
TBase extends Constructor & RequestSettings
Не нравится, что нужно статическое свойство url, а иначе никак из базового класса свойство не получается достать
Несмотря на то, что тс подсказывает теперь какие методы у инстанса есть, при наведении с ctrl на метод, чтоб посмотреть его сигнатуру выглядит все грустно
Но из всех вариантов, которые пришли в голову и подсказали этот самый удобный

можно так сделать, чтоб не писать такую конструкцию и статические поля не использовать

type RequestSettings = { 
    url: string 
} 
 
type Constructor<T extends RequestSettings> = new (...args: any[]) => T; 
 
function WithGet<TBase extends Constructor<RequestSettings>>(Base: TBase) { 
    return class extends Base { 
        get() { return this.url } 
  }; 
}

оу, вот это круто, спасибо еще раз, я пока с тс на "вы"

вот неплохой репозиторий для ознакомления с основными принципами и фишками TS https://github.com/mdevils/typescript-exercises
Вначале легко может показаться, но потом упражнения по сложнее идут

Кто как структурирует конфиги для деплоя и исходники, если это в пределах одной репы? Или как обосновать, что хранить Dockerfile и прочие конфиги для деплоя в папке с исходником (например в client/server) это плохой подход?

То есть структура такая:

./client
  ./src
  ./package.json
  ./Dockerfile
  ./*.yaml
./server
  ./src
  ./package.json
  ./Dockerfile
  ./*.yaml

против такой:

./client
   ./src
   ./package.json
./server
   ./src
   ./package.json
./deployment
 ./client
    /.Dockerfile
 ./server
    /.Dockerfile
 ./*.yaml

... хранить в попке с исходником ...

с таким подходом сильно разрастается рутовая директория клиента/сервера, как минимум это мозолит глаза (но как бы это и субъективная оценка, нужно какое-то твердое обоснование)