Всем привет! В предыдущем посте мы подробно поговорили про добавление зависимостей в проект и про способы и стратегии их обновления.
В этом посте, как и обещал, я хочу начать обсуждение таких невероятно важных вопросов, как стабильность и безопасность в управлении зависимостями. Надеюсь, мои советы помогут вам контролировать хаос, снижать риски и всегда оставаться на безопасной стороне!
И снова привет! В прошлом посте мы начали рассматривать процесс управления зависимостями в JavaScript, разобрали основы: что такое npm-пакет; как выглядит манифест пакета; в каких полях прописываются зависимости; что такое дерево зависимостей; а также основы семантического версионирования (semver). Если вы пропустили предыдущий пост, то рекомендую начать с него.
Сегодня мы пойдем немного дальше и подробнее рассмотрим, как работает semver, как правильно прописывать диапазоны зависимостей, а также устанавливать и обновлять их.
Мне, с того момента, как мы объявили о том, что в npm 7 будут поддерживаться файлы yarn.lock, несколько раз задавали один и тот же вопрос. Он звучал так: «Зачем тогда оставлять поддержку package-lock.json? Почему бы не использовать только yarn.lock?».
Краткий ответ на этот вопрос выглядит так: «Потому что yarn.lock не полностью удовлетворяет нуждам npm. Если полагаться исключительно на него, это ухудшит возможности npm по формированию оптимальных схем установки пакетов и возможности по добавлению в проект нового функционала». Ответ более подробный представлен в данном материале.
Читать полностью »
Пакетный менеджер npm становится частью GitHub. Объявления об этом появились и в блоге GitHub, и в блоге npm.
В блоге npm основатель проекта Айзек Шлютер подчёркивает «npm, который вы знаете, никуда не девается». Он выражает уверенность, что для проекта это перемена к лучшему, и сообщает, что сам продолжит работать над ним.
Читать полностью »
Прошлым летом, в процессе подготовки статьи для Хабра, я не поленился упаковать свой шаблон для бэкэнд-приложений на Node.js в npm-пакет, сделав из него cli-утилиту для быстрого старта.
Никаких надежд на то, что этим пакетом будет пользоваться кто-то, кроме меня, не было изначально. Однако, когда я решил обновить шаблон, внедрив в него нужные мне фичи, я обратил внимание на то, что у npm-пакета есть несколько десятков скачиваний в неделю, а у проекта на гитхабе 12 звёзд. Поставленные по доброте хорошими людьми, наверняка, чтобы поддержать меня, а не проект. Всего 12 звёзд, но мне этого хватило, чтобы решить, что karcass я буду развивать так, как будто он нужен не только мне.
Несмотря на то, что изначально я решил сделать легковесный фреймворк для бэкэнд-приложений, в процессе разработки мне удалось себя убедить в том, что этот велосипед не нужен. И что karcass должен стать не фреймворком, а универсальным инструментом для создания приложений из шаблонов.
Yarn — менеджер пакетов для ноды — выпустили вторую версию. И, похоже, парни серьёзно вознамерились изменить статус-кво в экосистеме ноды, а то и вообще в пакетных менеджерах. Удаляйте все свои картинки про гигабайтные мамки node_modules, убирайте yarn install из скриптов CI, мы начинаем очередную великую JavaScript-смуту. Если вкратце:
Если вы не хотите обновлять все ваши проекты, просто запустите
yarn policies set-version ^1(смотри legacy.yarnpkg.com/en/docs/cli/policies) в репозиториях, которые должны остаться на Yarn 1 и закомитьте результат. Тогда Yarn будет использовать локальные бинарники Yarn 1 вместо глобальных так что все в команде будут использовать одну версию!
Недавно я публиковал статью о том, как быстро настраивать npm-пакеты перед публикацией в opensource. В ней я разобрал настройку версионирования, CI, построение воркфлоу и удобный деплой на страничку с демо. Все советы той статьи распространяются и на библиотеки Angular. Но все же специфика Ангуляра не позволит вам развернуться сходу.
С шестой версии Ангуляра мы используем Angular Workspaces. Это отличный инструмент для организации проекта, но он может добавить сложностей при его первичной настройке для опенсорса. Мы решили предусмотреть их и автоматизировать процесс.
TL;DR. В большинстве категорий теперь выделяются явные лидеры — несколько лет назад такого не было. Это помогает накоплению знаний. Поэтому Навыки владения инструментами в среднем становятся глубже у разработчиков всех уровней.
В этом году 3005 разработчиков ответили на 27 вопросов, охватывающих широкий спектр инструментов и методологий фронтенд-разработки. Как всегда, огромная благодарность всем, кто нашёл время заполнить опросник. Со своей стороны, прошу прощения за задержку с публикацией результатов: в этом году работать было непросто из-за рождения малышки.
Как всегда, очень интересно посмотреть на изменения инструментов фронтенда за последние 12 месяцев и как меняются мнения разработчиков в отрасли. Эти результаты (надеюсь) помогут получить представление о текущих тенденциях и уровне освоения инструментов, а также об изменениях во времени, сравнив с цифрами из предыдущих опросов.
Итак, к делу! Возьмите чай/кофе/напиток на свой выбор и посмотрим на результаты…
Читать полностью »
Вот вы сделали что-то новое и крутое, приходит мысль — выложить в опенсорс и опубликовать в npm.
Просто запушить код в публичный репозиторий недостаточно. Это обречет проект на отсутствие развития и провал. А с другой стороны вспоминается целый ряд скучных процессов: версионирование и публикация пакета, настройка непрерывной интеграции, хостинг и деплой странички с демо проекта, организация возможности контрибьютинга для комьюнити.
Если вы хотели опубликовать небольшой пакет, то такой набор работы может сильно отпугнуть. Светлая идея поделиться чем-то полезным уйдет в долгий ящик сложных дел.
На самом деле всё это может занять у вас меньше часа. Без знаний DevOps и совершенно бесплатно.
Привет. Это статья о том как настроить построение на всех платформах с помощью github actions.
