Дмитрий Беляев

Реализация перегрузки должна содержать в каждом аргументе юнион из всех возможных комбинаций, то есть в Вашем случае так:

function getProductCollection(func:
    | ((error: Error, data: null, info: string) => any)
    | ((error: null, data: ProductUnit[], info: string) => any)
): void {}

Дело в том что тип

((error: Error, data: null, info: string) => any) | ((error: null, data: ProductUnit[], info: string) => any)

Это совершенно не тоже самое, что

(error: null | Error, data: ProductUnit[] | null,  info: string) => any

Ну и кстати, перегрузка в таком случае не особо нужна, и даже вредна.

Так же у такого типа есть 2 проблемы:
1. Колбэк func не вызвать нормально, так как без каста все аргументы обобщаться до типа never
2. Код вызывающий getProductCollection не сможет получить нормальные типы для колбэка, ему нужно будет явно указать типы 1 из вариантов, что опять же делает такой тип крайне бесполезным.

Можно сделать перегрузку самого колбэка:

function getProductCollection(func: {
    (error: Error, data: null, info: string): any;
    (error: null, data: ProductUnit[], info: string): any;
}): void {}

Это защитит внутренности getProductCollection от его неправильного вызова, но снаружи, Вы получите в колбэк обобщенный тип:

(error: null | Error, data: ProductUnit[] | null,  info: string) => any

Это заставит вызывающий код делать или лишние проверки, или кастовать типы, так что если не нужны сильные гарантии в пределах одной функции, то можно обойтись простым вариантом:

function getProductCollection(func: (error: null | Error, data: ProductUnit[] | null,  info: string) => any): void { }

P.S. не используйте тип any никогда, в Вашем случае лучше использовать тип void в качестве возвращаемого типа для колбэка, если Вы его никак не используете.

Ну и еще, взгляните на типизацию ноды:
https://github.com/DefinitelyTyped/DefinitelyTyped...
https://github.com/DefinitelyTyped/DefinitelyTyped...
Может не стоит усложнять использование Вашей функции вариативностью типов для data?
И почему бы вообще не использовать промисы вместо колбэков?

Все встроенные модули зашиваются в исполняемый файл ноды (.exe под виндой или elf-бинарь под линукс) при ее сборке и компиляции.
При желании туда можно и свои модули добавить, как это делает например electron.js, но придется ноду собирать из исходников, а это не очень быстрый процесс.

Ну а ссылку на исходник уже дал lssssssssssl, там рядом (в папке lib) и другие модули посмотреть можно

if (hours === 10 || (hours === 11 && minutes < 30)) {
  // 1
} else if ((hours === 11 && minutes >= 30) || hours === 12) {
  // 2
}

Но проще вычислить даты для контрольных точек и сравнивать текущее время с ними:

function createDate(hours, minutes) {
  const d = new Date();
  d.setHours(hours);
  d.setMinutes(minutes);
  return d;
}

const time1 = createDate(10, 0).getTime();
const time2 = createDate(11, 30).getTime();
const time3 = createDate(13, 0).getTime();
const now = Date.now();
if (now >= time1 && now < time2) {
  // 1
} else if (now >= time2 && now < time3) {
  // 2
}

Ну и так же стоит учитывать, что считать это все будет в часовом поясе пользователя, если же нужны вычисления независимые от часового пояса, то стоит использовать методы setUTCHours и setUTCMinutes со смещениями нужного часового пользователя относительно UTC (Лондона) ну или getUTCHours/getUTCMinutes для первого варианта.

А кто текст ошибки будет читать?

Uncaught TypeError: [1,2,3] is not a function

Лучше всегда использовать точку с запятой, чтоб таких ошибок не было.
Конкретно тут возникает ситуация, что круглые скобки вокруг функции являются продолжением выражения с массивом, то есть работает это по сути так:

let map = [1, 2, 3](async () => {
	console.log(map)
})()

Для отправлять запросы из ноды есть вот:
https://nodejs.org/dist/latest-v17.x/docs/api/http...
https://www.npmjs.com/package/node-fetch

Для принимать:
expressjs.com/en/4x/api.html#app.post.method

настройки запуска находятся в файле .vscode/launch.json
добавьте туда параметр cwd со значением "${fileDirname}"

https://developer.mozilla.org/ru/docs/Web/CSS/scro...

Дизайн паттерны абстрагированы от языка и работают практически везде одинаково. Некоторый отпечаток может наложить на них динамическая типизация, как в JS, но даже тут сильно ничего не поменяется.
Кроме того, в корне не верно приписывать паттерны к ООП. Они абсолютно одинаково работают во всех парадигмах, за некоторыми небольшими исключениями.
Ну и наконец, ООП часть в TS прямо слизана с Java, так что многие примеры будут даже выглядеть похоже.

Не нужно явно писать типы там, где typescript способен вывести их сам. И тем более нужно избегать приведения типов через as:

function loop(step: number) {
    for (let i = 0; i < 100; i += step)
        console.log(i);
}

В данном коде нет ошибки, ошибка в другом месте. Typescript вообще не меняет логику в выходном javacript. Я бы поискал другие места, где Вы вызываете эту функцию. Где-то Вы передаете в нее строку, убедив typescript через оператор as, что это число.
Тут важно понять, что от as ничего не останется в javascript, typescript не сгенерирует приведение типов за Вас.

U - это имя которое вводите Вы, вместо него может быть любое валидное имя:

type InferValueTypes<T> = T extends { [key: string]: infer IDontKnowWhat2CallThis } ? IDontKnowWhat2CallThis : never

А вообще не надо использовать условные типы, особенно с infer, там где можно обойтись без них:

type InferValueTypes<T extends Record<string, unknown>> = T[string];

Очень много где эти 2 оператора взаимозаменяемы и результат будет равносильный.
Однако пару различий все же есть:
1. interface поддерживает declaration merging, а type - нет. Это бывает полезно для библиотек, которые позволяют расширять свое api, например через плагины.
Так же, при проверке типов, typescript будет учитывать для interface, что он может быть расширен за пределами текущего проекта что наложит ряд ограничений.
2. type позволяет вычислить тип. interface имеет гораздо меньше возможностей в этом плане.

Вообще это дело вкуса, но для себя я выбрал следующий подход:
Использовать interface для типов которые экспортируются из библиотеки/npm-пакета и подразумевают возможность внешнего расширения описываемой сущности.
Во всех остальных случаях использовать type.