Комментарии 68
А зачем вы собранный бандл в гит вообще кладёте?
Это всё конечно хорошо и правильно, но при чём тут гит? Зачем класть бандл в гит?
чтобы его не надо было собирать тем, кому это не надо
Для этого есть npm, CDN и вкладка Releases на гитхабе, а артефакты сборки обычно наоборот прописывают в .gitignore
это иденпотентный бандл, бывает жизнь без нпм и я не хочу делать людям квесты
Вы создаёте людям квест по выковыриванию бандла из гита, нехорошо
Ну вот за явно нетрадиционный подход вы и собираете минусы)
Для этого есть README.md где обычно написано как пользоваться библиотекой. А если не написано, то это повод усомниться в качестве библиотеки.
В современном мире, даже минифицированные js-файлы для крупных проектов будут отличаться по своему содержанию. Наличием полифиллов или альтернативных решений.
А еще можно поддерживать React Native, скажем. Там свои нюансы и возможности.
Так что, своим комментарием сами же себя и опровергли
В современном мире, даже минифицированные js-файлы для крупных
поэтому я не минифицирую этот бандл и не включаю в него полифилы. Есть например люди которые делают еще cjs сборку считая, что это им поможет поддерживать большее число архитектур и они точно также складывают их в build/ и dist/. И если вы загляните в node_modules там вероятно большее число пакетов будет иметь такие сборки.
А зря. Первое место, где её следует искать — это вкладка Releases.
Для тех, кто живёт без npm, существует https://unpkg.com/
тут могут быть разные способы и регламенты
а как они на гитхаб попадут тогда?
Можно пользуясь случаем срошу? Зачем они вообще должны туда попадать?
Свой сервер для описанных выше задач должен устроить полностью. И поднять его — задача ну максимум на пол часа. Что даст гитхаб кроме пиара?
А дальше начинаются соображения всякого дальнего порядка, которые во основном сводятся к тому, что городить свой велосипед — плохо (пока очень четко не понимаешь, зачем тебе этот велосипед нужен), а пользоваться общепринятыми в индустрии инструментами — хорошо.
кроме того, сторонний сервис вас может забанить или замедлить и вообще их использование хорошо только для хттп1 а с мультиплексированием хттп2+ скорее пагубно. unpkg это в самый раз для демок на кодепен, но как единственно возможный вариант не годится. Для обеспечения совместимости с разными модульными форматами включение нескольких точек входа это обычная и даже рекомендуемая часто практика.
В npm пакет класть бандл — согласен. А в гит зачем?
Ну и ещё «вопросы»:
- собирать дебаг или релиз?
- а если я очень хочу закоммитить поломанный код в какую-то временную ветку? (решил что-то сделать по-другому, но не уверен и хочу сохранить текущий прогресс, например)
- делать ли full clean перед сборкой? А если бандл собирается с нуля 2 минуты?
вспомнил ещё одну причину: я часто ставлю версию прямо из мастера (git+https://, git+ssh://) для проверки гипотез и тестирования до публикации. так гораздо проще добавлять и проверять измения и вариант с бандлами только в пакете мне не подходит никак.
Мне эта библиотека кажется странной.
Чтобы запустить что-то (не обсуждая, что) перед коммитом, думаю лучше использовать husky, потому что там есть и другие гитовые хуки, которые смогу понадобиться со временем.
мне была бы понятнее секция pre-commit чем новое слово на букву ху:)это более чем характеризует вас, как спеца. И где «вы такие» беретесь только )))
ну я не сцу кипятком от слова CI… но у меня и без этого все работает довольно быстро с этой библиотекой даже на стареньком ноуте.
Вот бы мне на интервью кто то отмочил подобное, но к сожалению такие
А почему бы для этого не использовать CI? Чтобы сэкономить своё время/головную боль с хуками, и это проще масштабируется на несколько разработчиков
(вот мой недавний пример: https://github.com/materializecss/materialize, тут dist на много коммитов отстал от кода)
Сейчас существует достаточно cloud CI, вам даже ничего поднимать не нужно, только настроить аккаунт один раз
когда я вижу библиотеку которую мне надо подключить статически, я первым делом ищу dist/, если его нет я буду пытаться ее собрать или искать другую
Я честно говоря не знаю, как "принято" в нпм мире, но мне кажется более логичным использовать для этого как минимум GitHub releases (или нечто подобное). Хотя логичнее всего выглядит npmjs или какие другие репозитории
И, в моём скромном опыте, для подключения npm библиотеки из гитхаба, дист не нужен, нпм может подхватывать по прямой гитхаб ссылке
И, в моём скромном опыте, для подключения npm библиотеки из гитхаба
можно подключать ее как esm модуль, можно статически, я сделал оба варианта чтобы она подходила для всех случаев. Например на какой-нибудь жуткий вордпрес шаблон или что-то такое.
Полезность CI не зависит от размера бандла.
Я рад, что вы решили попробовать )
Вот пример, как из трависа сделать коммит в гитхаб обратно:
https://gist.github.com/willprice/e07efd73fb7f13f917ea
Разумеется, на изначальную настройку и изучение Travis (или любого другого CI, который вы решите попробовать) вам понадобится время. Но изучение новой технологии всегда полезно и пригодится в будущем
Но в целом ваш финальный CI файл может выглядеть примерно так:
dist: bionic
language: node_js
node_js:
- '15'
script:
- npx rollup --config rollup.config.js
after_success:
- .travis/push.sh
env:
global:
secure: YOUR_ENCRYPTED_GITHUB_KEY
Как по мне, это не "из пушки по воробьям", а вполне себе лаконично
…то там есть свой CI
В остальном, я сторонник того, что номером первым всегда должен идти результат. Если результат есть, тогда можно уже обсуждать недостатки процесса. Если же переделка процесса выльется в отстутствие результата — это уже теоретический спор ради спора, а не что-то нужное в реальной жизни.
Честно говоря, мой посыл был в другом: мне хочется, чтобы начинающие разработчики, прочитав эту статью, прочитали и мой комментарий. И вместо того, чтобы городить свой огород с хуками и локальными решениями, использовали более популярные стандарты. Это облегчает работу другим разработчикам (и даже себе будущему)
Если у автора всё работает, он всё делает с одного компа, и никто его код трогать не будет, то решение себя оправдывает. Конечно, ничего переделывать не нужно.
Но, возможно, задуматься о более подходящих инструментах для новых проектов. Если их использование не сопряжено с чрезмерными трудностями.
ПС "я не сцу кипятком от слова CI" тоже. Для меня CI = автоматизация, и вот она действительно важна. Решение с хуками, как по мне, это недо-автоматизация.
ППС я тоже начинал с ручных поделок и хуков (да и сейчас они есть). Но единственная причина их иметь, как по мне, это лень и чрезмерное количество свободного времени, чтобы тратить его вручную
не мучиться потом с rebase каждый раз
А какие с ним мучения? Интерактивный ребейз, удобный редактор и как бы всё — история ветки получается красивой и логичной, а не 100500 тупых коммитов о метании мысли, забывчивости, мёрдже мастера из оригин мастера и прочего треша.
Хотя ваш подход хранения артефактов в гите сомнителен.
Теперь прямо перед коммитом сразу собирается бандл и добавляется в коммит.о_О кто то реально использует такое на практике? А что делать, если бандл пару сот мегабайт или пару гигабайт? Чем не устроило хранение бандлов/артефактов в том же Artifactory?
он будет в браузер загружен, если вы туда пару гигабайт готовите, это и в самом деле проблема
и конечно бандл это не всегда артефакт, мой код не надо компилировать, чтобы он заработал. Вам тайпскрипт и SPA совсем мозги зафимозили похоже.
Не могу найти в комментарии, на который вы отвечали, слово "компиляция" или однокоренные с ним. Кажется, это вам тайпскрипт и SPA "мозги зафимозили", только в другую сторону — в любом комментарии вы почему-то видите намёк на них...
Перед коммитом