Aetae

Ну какбэ в чём проблема то?

let lineNumber = 0;
rl.on("line", (input) => {
  lineNumber++;
  ...
  if(lineNumber >= 2) rl.close();
});

Или типа того.

Верить клиенту конечно нельзя, но можно сделать вид что веришь:
1. рассчитывай число и на клиенте и на сервере.
2. в начале расчёта один раз синхронизируй с сервером.
3. выводи рассчитываемое на клиенте число с какой угодно плавностью.
4. если синхронизация прям очень важна - продолжай слать число с сервера и сравнивать с клиентом, если разница в пределах (заданной) погрешности - ничего не делай, еслы вышла за пределы - меняй клиентское(ничего страшного если такое будет происходить изредка).
5. если сама по себе синхронизация не особо важна, а важно лишь конечно число, то собственно сравнивай клиентское с серверным только в самом конце. Если совпало (с погрешностью в нужную сторону) - всё ок. Не совпало - клиент хацкер - идёт нафиг.

У любого нормального клиента всё всегда будет совпадать, мегаредкие исключения со сломанными системными часами в любом случае будут баговать, а хацкеры нам и не нужны.

results.unshift({ id: 0, text: 'Без категории' });

Object.assign - работает как называется: assign, не add, append, push или ещё как-то. Он присваивает первому аргументу ключи второго(т.е. перезаписывает, если такие у присутствуют). В случае массива ключом является индекс.

Никаких setTimeout точно.
Просто при каждом поступающем сообщении создаёте задачу на временную метку(можно с помощью совета Станислав Макаров) если такой ещё нет, которая в указанное время запросит все записи с такой меткой и выполнит с ними нужное действие.
Метку и, соответственно, запрос можно создавать с округлением в размере допуска.
В базе естественно всё это дело надо индексировать и складывать для удобства таких запросов.

Ну как обычно со всем остальным: вынести в общую библиотеку либо вынести в гит-модуль.

webpack devServer, в частности функция proxy.
Webpack поднимает сервер с горячей перезагрузкой фронта, бэк сервера поднимаешь на других портах, и обращаешься к api прозрачно с помощью встроенного прокси.

Как-то так (не проверял):

interface CreateConnectionOptions extends ConnectOptions {
  retryCount?: number;
  retryDelay?: number;
}

function createConnection(uri: string, {
  retryCount = 6,
  retryDelay = 1000,
  ...mongooseConnectOptions
}: CreateConnectionOptions = {}): Observable<Connection> {
  let connection$ = defer(() => mongoose.createConnection(uri, mongooseConnectOptions).asPromise());
  
  if (retryCount > 0) {
    connection$ = connection$.pipe(retry({
      count: retryCount,
      delay: retryDelay
    }));
  }
  
  return connection$.pipe(shareReplay(1));
}

Как обычно:

Discord.Client.prototype.funcname = function(arg) { ...};

Подозреваю # в пути лишний.

Каждый раз когда меняется props.jwtAccessToken или создаётся новый компонент - вызывается useMemo. Каждый раз как вызываются useMemo - добавляется ещё один interceptor.

Interceptor надо вешать, очевидно, один раз одну штуку.

При установке зависимостей этот модуль и так окажется в корне. Если у тебя оказывается две версии одного модуля - одна твоя в корне, другая в подпапке другой зависимости - это плохо и бессмысленно раздувает бандл. Старайся обновлять всё зависимости чтоб такого не было. На крайний случай можно использовать yarn resolutions или установить себе ту же версию что и зависимость.
А по вопросу, если всё таки такое случится - никакой разницы, кроме того что ты это никак не контролируешь.

У тебя похоже циклические ссылки: vk.js запрашивает database.js и наоборот. В таких случаях кто первый встал того и тапки.
Выноси общий функционал в отдельный файл.

Ну ошибка жалуется на отсутствие python. Попробуй установить.

Однако подозреваю дело в версии Node, последняя LTS ток неделю как вышла и пакеты могут парить мозги.

Мужик, если не знаешь английского - используй гугл транслейт.
Давай я пока сделаю это за тебя:

Не удалось загрузить сценарий модуля: ожидался сценарий модуля JavaScript, но сервер ответил типом MIME «text / html». Для скриптов модуля в соответствии со спецификацией HTML применяется строгая проверка типов MIME.

Что тут непонятного? Ты не знаешь что такое MIME тип? Так погугли, это важное знание для любого веб разработчика. Хотя можно и догадаться из контекста.

Как исправить? Поправить MIME тип на сервере, вестимо. Как это делается для конкретного сервера гуглится, вполне очевидно, по фразе "<имя сервера\серверного языка> MIME type".

Ну и есть некоторый шанс, что вместо скрипта тебе отдаёт 404 страницу, проверь перед всем остальным.

await page.on('response', response => {
->
page.on('response', async response => {.

page.on не возвращает Promise, он подписывается на события.

Это очевидно, но на всякий случай: то что просходит в callback'e page.on - это уже будет отдельный асинхронный (псевдо)поток, который пойдёт параллельно основному.

Если вы уверены, что это событие сработает только раз, и вам надо его дождаться в основном "потоке", то следует вручную завернуть его в Promise, условно так:

const json = await new Promise(resolve => page.on('response', function onResponse(response) {
  if (response.url() == "https://capuk.org/ajax_search/capmoneycourses") {
    page.off('response', onResponse);
    resolve(response.json());
  }
})); 
console.log('XHR response received');
console.log(json);