Comments 18
Я бы сказал, пора переходить на bun в новых проектах. Перетягивание застарелых монстров из Node мало что даст.
Husky ? Really ? Зачем эту фигню поддерживать в принципе, которая ничего не даёт
Я не поклонник Husky, но проверки перед коммитом, это действительно большое преимущество при создании open-source проекта с участием других разработчиков.
`simple-git-hooks`? Гораздо легковеснее, а работу выполняет не хуже
Спасибо, я посмотрю. Надеюсь, что установить будет проще, чем Bun
В последних версиях husky заметно похудел и теперь сравним с simple-git-hooks
И так слишком сократили код в husky, даже переменные одной буквой называют. Куда уж легковеснее
Используйте lefthook, вам больше не нужен husky и lint-staged
Спасибо
Зачем вообще полагаться на хуки гита и греть комп разраба на коммитах когда можно в ПРах проверки прописать по стилю и тестам? Тогда возможность раздать стрёмный код обрубается на корню, а мотивация каждого участника настроить IDEшку повышается - чтобы красным светилось ещё до коммита.
А ещё желаю удачи тем, кто собирается ОС-независимые хуки сваять. Ну, чтобы разрабов с виндой не блочить своим никсовым bashизмом. Там похлеще извращаться приходится, чем для написания платформонезависимого кода самой программы.
Особенно не понимаю тех, кто в husky и подобное всякую ерунду прописывает секунд на 30 и дольше (типа все тесты прогнать). То, что занимало 0 сек, превращается в чаепитие.
Мы используем хуки на push, а не на коммит, что вполне приемлемо с точки зрения DX. Проверяем типы, запускаем линтер и выполняем дополнительные проверки.
В CI проверки тоже конечно есть. Это нужно как раз в первую очередь для экономии времени, потому что когда у вас сложный пайплайн, то он выполняется долго и не хочется чтобы он падал из-за линтера.
Согласен, какую только ерунду не ставят, лишь бы маны гита не читать
Как обычно.
Перешел на бун пару месяцев назад но начал писать с нуля новые микросервисы. Проект активно развивается и много чего еще нет. привлекло то что можно собрать проект в один бинарник и запустить в дистролесс контейнере но мультитредовое прилождение таким образом работать не хочет. Проверю еще раз на версии 1.4. ну и руки не доходят проверить производительность стресс тестированием. хотя я и так использовал uWebsocket.js который встроен в бун так что разницы особо наверное не будет. но попробую переписать какойто микросервис на express.js и сравнить результаты
Какой-то неполноценный переход на Bun, потому что у вас в качестве бандлера используется депрекейтнутый tsup, а для запуска тестов vitest. В Bun есть встроенный бандлер, который будет однозначно быстрее и так-же есть встроенный jest-совместимый тестраннер, у которого, в версии Bun 1.3, появилась возможность запускать тесты параллельно, благодаря этому он стал быстрее vitest.
Я попробовал бандлер Bun, и там нет опции bundle: false, из-за чего возникают ошибки с next-intlayer
Если указать несколько точек входа, расширения не разрешаются.
Я был бы очень рад перейти на их бандлер, но он всё ещё на очень ранней стадии.
Поэтому я остаюсь с бандлером на основе esbuild
И я доволен Vitest, не хочу переносить все тесты своего кода
Согласен, бандлер Bun имеет мало настроек и подойдёт далеко не всем. Я сам где-то использую esbuild вместо него.
А bun test на моих тестах отрабатывал примерно в 10 раз быстрее vitest, но такого результата можно добиться только на синхронных тестах. Если в проекте есть много асинхронных тестов, то, из-за ожиданий, результат будет менее значительным.
Bandler bun можно использовать только для приложений написанных на bun для повышение скорости (target: bun) для остальных вещей использовать неэффективно. Кстати с rolldown vite билдится быстрее, но подойдёт тем у кого esm только. Хотя использовать cjs это вообще не про скорость.
Использовать bun вместо npm давно можно. Но все же как runtime начинать проект опасно. Что-то вечно до конца работает ни так. Редиска с сертификатом не подключается, хотя писали что cyphers добавили. На машине с proxmox не запускается хотя делаю baseline билд.
А вообще очень часто начинаешь использовать Bun утилиты, а потом все равно подключаешь node библиотеку. При всем желании использовать максимально Bun не выйдет, спасает совместимость с nodejs.
Я мигрировал свой монорепозиторий на Bun — вот мой честный отзыв