Везде будут делать. Потому, что для думающего человека глабал можно, а require не всегда хорошо. Ну если у человека закомпостированеые мозги и он считает что global нельзя просто потому, что нельзя и не понимает почему именно, ну тогда ему require не поможет, он через require напишет такой же говно.

жаль там не тайпскрипт, существенно снижается полезность стартер кита)
но все равно круто, можно подсмотреть идеи 👍

Require неявно создает синглтон, а синглтон - это то же, что и глобал. Главная идея в связывании через интерфейсы, а не через данные.

В js можно использовать контрактное программирование и передавать объект с методами. Как, например, всем известные контракты thenable и iterable

Да, это конечно работает, но при нарушении интерфейса ошибки сыпятся в рантайме. А тайпскрипт принципиально не использовали или не хотели усложнять стартер кит?

Все, что экспортируется, должно быть доступно через методы и может мутироваться только из своего класса или модуля. Не важно, через глобал или через require. Конечно я рекомендую всем экспортировать пул конекшенов к базе через глобал. Но даже обычную переменную-счетчик через require нельзя экспортировать.

а почему конфиг просто файлы а не .env?

Если все покрыто тестами, а только так и может быть, то в рантайме ничего не сыпется. Тайпскрипт я использую, но стартер будет сначала для js.

Глобал везде доступен и это позволяет использовать его для экспорта и импорта. Это ни чем не отличается от module.exports и require

Вопрос про DI. Один из моих прошлых проектов был написан полностью функциями. Без классов. Node.js модули экспортировали чистые функции (без состояния), вход - трансформация данных - выход. Тестируемость такого кода - шикарная. Зачем в подобного рода программах вводить dependency injection?

У меня такое ощущение что из-за dependency injection - там где можно обойтись очень хорошо тестируемой чистой функцией - начинают писать классы, имеющие состояние. А состояние потом корень многих проблем.

Ссылок на объекты тоже небыло? req и req не было?

входящий req передавался по цепочке ряду функций и получался ответ

это не чистые функции, чистые функции не должны общаться с объеками, которые созданы вне их

A pure function is a function where the return value is only determined by its input values, without observable side effects  - на вход приходит req.body, на выход выходит напрямую зависящий от входа обьект - чем не чистая?

то есть все эти функции работали с req ? разве это не делает сквозную связанность с req? и в случае изменения интерфейса req - необходимость рефакторинга все функций завязанных на req ?

req.body по факту проезжал через весь этот ряд трансформаций. не сам req

при вызове функции 1 и 2 раз, разве одинаковый аутпут будет?

определение правильное, а интерпретация - нет, req и res - это средоточие состояния, это как глобал, ни чем не лучше. в общем, у вас был проект, написанный полностью на функциях с побочными эффектами

да, 200% - при одинаковом входе - один и тот же выход

то есть body  отделялось от req, приводилось к виду, который необходим для функций-потребителей, есть есть некий контракт - если так то норм, как по мне