Наступил 2021 год, и вам, вероятно, понадобится использовать JavaScript в ваших приложениях на Rails больше, чем когда-либо. Экосистема JavaScript радикально изменилась в лучшую сторону за последние несколько лет. Сборщики модулей полностью взяли на себя выполнение задач, Babel почти повсюду, а ES6 изменил способ написания нашего кода.
Но с другой стороны, общая сложность управления нашими активами с помощью этих новых инструментов резко возросла. Таким образом, в большом приложении, таком как Per Angusta, его может быть очень сложно обновить и, вероятно, совсем не обязательно. Давайте посмотрим, почему и как мы управляем зависимостями в Per Angusta.
Прежде чем начать, я - Гийом Бридей, ведущий разработчик Per Angusta и гордый член организации Rails, которая управляет и вносит свой вклад в Webpacker.
Зачем вообще нужны зависимости?
В наши дни для создания веб-сайта нам потребуются тысячи строк кода. Это может быть CSS или JavaScript, но в обоих случаях мы хотим использовать надежный код, написанный другими людьми. Это хорошо, для этого предназначен открытый исходный код!
Например, мы можем установить Bootstrap для быстрого прототипирования или Flatpickr, если вам нужен мощный инструмент выбора даты и времени. Чтобы написать его самостоятельно, потребуются месяцы или годы. Поскольку эти библиотеки используются тысячами или миллионами людей, ошибок почти не существует и производительность, вероятно, высока.
У этих пакетов есть другие зависимости, которые также имеют другие зависимости и так далее. Для всех этих зависимостей могут потребоваться разные версии одной и той же библиотеки, и, как вы догадываетесь, станет очень сложно управлять этим вручную, а обновления могут стать почти невозможными.
Большую часть времени мы заканчивали тем, что создавали папку vendor со всеми зависимостями в ней, включая их зависимости, и никто не трогал ее в течение многих лет. Это может быть недостаток безопасности, и вы не сможете пользоваться новыми функциями любимых пакетов.
Менеджер пакетов: Пряжа
Yarn (и npm) для JavaScript - это то же самое, что Bundler для Ruby. Диспетчер пакетов.
Его роль - иметь дело со всеми зависимостями, которые могут вам понадобиться в ваших проектах. Вместо того, чтобы копировать и вставлять тонны файлов в вашу папку vendor, Yarn прекрасно с этим справится. Если у вас есть конфликты зависимостей, он будет разумно управлять этим за вас, и вы можете иметь две версии одного и того же пакета, если это потребуется.
Более того, наличие хорошо известной папки vendor в вашей VCS затрудняет поиск версии пакета и обновление в Pull Requests.
С помощью диспетчера пакетов вы объявите все необходимые зависимости с их версией в файле JSON с именем package.json. Это будет единственный источник правды о ваших зависимостях.
Yarn будет использовать этот список зависимостей для их установки и управления. Больше никаких vendor папок в вашей VCS и упростите просмотр и обновление Pull Requests!
Это определенно огромная победа в нашем рабочем процессе разработчика. Более того, он предоставляет реальный способ аудита уязвимостей безопасности с помощью автоматических инструментов, таких как аудит пряжи или зависимость, что практически невозможно с папкой поставщиков. Вы также можете автоматически проверять совместимость вашей лицензии с Licensed.
Вот пример package.json:
Вместо того, чтобы наша папка vendor выглядела примерно так с (потенциально) неизвестными версиями:
После установки папка node_modules будет содержать все ваши зависимости.
Зависимости JavaScript в приложениях Rails
Несколько лет назад не существовало ни npm, ни Yarn. Мы использовали для установки наших зависимостей JavaScript и CSS, как мы только что видели выше, или через сборщик как Gem. Обработка проводилась через Звездочки, и все работало нормально.
К сожалению, пакеты JavaScript и CSS нельзя использовать как есть с Bundler и Sprockets. Создатели пакетов должны создать версию Gem своих пакетов. Это резко снижает количество доступных пакетов, потому что разработчик почти не беспокоится об этом, поскольку существует Yarn. Вот, например, официальный гем Bootstrap.
Так что было бы здорово использовать вместе пряжу и звездочки, не так ли?
Как использовать пряжу с рельсами и звездочками
Но что такое звездочки в первую очередь?
Sprockets - это библиотека Ruby для компиляции и обслуживания веб-ресурсов для Rails. Проще говоря, Sprockets выполняет две функции: предварительно обрабатывает, а затем объединяет ваши ресурсы в файлы, готовые к производству. Эти ресурсы могут быть получены из драгоценных камней или из вашей vendor папки.
Теперь вместо того, чтобы извлекать эти файлы из папки vendor, мы могли бы получить их в папке node_modules и позволить Yarn управлять ими за нас! Все, что нам нужно сделать, это добавить дополнительные ресурсы в путь загрузки Sprockets. В config/initializers/assets.rb добавьте эту строку:
Теперь мы можем установить несколько пакетов. Например:
И свяжите его в manifest.js файле Sprockets:
Эта ссылка требует наличия файла node_modules/handsontable/dist/handsontable.full.js под капотом!
Это так просто? Да! Sprockets - это действительно просто.
Почему не только Webpacker?
Если вы используете Rails 5.2+, вы могли заметить, что Webpacker находится в Gemfile по умолчанию.
Webpacker - это оболочка для Webpack, облегчающая интеграцию с Rails. Webpacker не предназначен для замены Sprockets.
Благодаря быстрой эволюции JavaScript на протяжении многих лет экосистема JavaScript обнаружила, что необходимо пойти дальше, чем просто компилировать библиотеки в один и тот же файл для производства.
Webpack намного мощнее Sprockets, когда речь идет об управлении активами JavaScript. С помощью Webpack вы можете:
- Работайте с модулями вместо того, чтобы загрязнять глобальный масштаб.
- Встряхните свой код, чтобы повысить производительность и избежать огромных объемов полезной нагрузки.
- Разделите файлы так, чтобы загружался только тот код JavaScript, который необходим на странице.
- Напишите JSX или получите совершенно новый формат файла, например Vue’s SFC.
- И так далее…
Эти функции хороши, но не обязательно для ваших проектов, и бесплатны для ваших команд.
Сложность Webpack намного превосходит Sprockets! Никогда не забывай об этом.
Как написать современный JavaScript с помощью Sprockets?
Sprockets 4 представил много новых функций для написания современного JavaScript. Одно из них - поддержка синтаксиса ES6 с включенным препроцессором Babel. Это означает, что вы можете написать ES6 JavaScript и перенести его для браузеров, которые не поддерживают его изначально. Это полностью прозрачно и происходит во время сборки.
Но в зависимости от браузеров, на которые вы нацеливаетесь, вам, вероятно, вообще не понадобится транспиляция.
Например, этот фрагмент кода написан на ES6:
Почти во всех браузерах этот код будет работать «как есть». Что идеально! Но если вам все еще нужна поддержка Internet Explorer, этот код полностью выйдет из строя.
А вот и Список браузеров. Вы можете указать целевые браузеры в файле с именем .browserslistrc:
С помощью этой конфигурации мы можем сообщить Babel, что нам нужно сделать JavaScript скомпилированным для IE 10 и выше, а последние 2 версии поддерживаются всеми другими браузерами. Наш исходный код будет автоматически перенесен в:
Этот код совместим со всеми браузерами! Это ES5 JavaScript, который мы писали вручную в старые добрые времена. 😅
Список браузеров также используется многими инструментами, такими как Autoprefixer. Поэтому не забудьте добавить этот файл в свои проекты, даже если вы не пишете ES6.
Заключение
Прежде чем перейти к новому модному инструменту, который появляется в ленте вашего твиттера, вам обязательно следует остановиться на том, что работает для вашей команды и особенно для ваших клиентов. . Sprockets действительно потрясающий, и с появлением importmap и jsbundling вам может вообще не понадобиться переходить на Webpacker.
Хотите присоединиться к команде энтузиастов-разработчиков?
Мы набираем талантливых людей!
Узнайте больше о команде и наших вакансиях здесь:
