Comments 26
Развивать опенсорсные проекты не для разработчиков очень грустно. Мало того, что они мало кому нужны, так еще и те, кому они нужны или нравятся, не умеют в код.
Вот числа из моего проекта, за прошлый год:
9000 людей, запустивших мой проект хотя бы раз
900 людей, запустивших его повторно
600 людей, запустивших его на 2-й и далее дни
+10 звезд
+4 форка
+1 контрибьютор
+1 пиратская копия (да-да, опенсорс тоже можно спиратить).
burgomaster?
Как вы осуществляете мониторинг (собрали эту статистику)?
В коде есть два счетчика - Я.Метрики и Гуглоаналитики.
Они, в том числе, показывают, если моя игра была где-то еще установлена.
Насколько я понимаю, речь идёт о проекте https://github.com/Areso/1255-burgomaster? Тогда всё понятно. Я сначала подумал, что вы говорите про обычную NPM-библиотеку.
Когда для запуска dev-сервера не нужно собирать 50мб бандл - это удобно. Уверен, через несколько лет фронтенд разработка будет вестись с использованием только таких сборщиков. Всё-таки приятно, когда dev-сервер стартует за пару секунд. Правда, лично я использую не Snowpack, а Vite - он мне показался более продуманным. А ещё Vite использует Rollup (который мне кажется очень удобным) и Esbuild, с которым сборка получается ещё быстрее, потому что он написан на Go. В Vite зависимости бандлятся в один большой кусок и не пересобираются, если нет изменений. А внутренний код проекта уже загружается модулями по требованию. Всякие вебпаки после такого кажутся чем-то архаичным и необоснованно медленным.
А как при этом решаются проблемы эффективной доставки пользователю (релизный билд всё-таки бандлится?) и проверки корректности проекта (помню счастье перехода с js на ts)?
(я достаточно далёк от фронтэнда, но мало ли – и в моих задачах пригодится, ускорить сборку – всегда хорошо).
Да, prod-версия - как обычно, потому что, даже с учётом http/2, один большой файл загружается быстрее, чем много маленьких.
А проверка корректности? По мне, это даже важнее, бандлинг на крайняк сверху прикрутить можно, а знание, что никто из коллег не поменял сигнатуры функций – бесценно.
Ну, с TS проблем нет, там он встроенный. По запросу TS-файлик транспилится в JS и передаётся браузеру. В остальном - всё как обычно.
Т.е. об ошибках компиляции ts узнаете лишь зайдя на страницу, где он используется?
В консоли же или в браузере
Кажется, я немного наврал про встроенный TS. Сейчас вспомнил - из коробки делается только транспиляция, а для проверки нужно прикручивать плагин, например, vite-plugin-checker или что-то вручную делать. Проверку можно настроить как угодно, мне кажется. В том числе и авто-проверку при сохранении файла, но я не углублялся в это. Мне в проектах с Vue хватает запуска vue-tsc --noEmit перед коммитом.
Когда я последний раз что-то делал под веб фронтенд, там еще было модно использовать Babel для JS, пре- и пост-процессоры CSS. Как я понимаю, это же не будет работать в случае сборщиков, подобных обсуждаемому в статье?
Простите, если фигню несу, далек от современного фронта.
Но особенность сборщиков такова — что точно все настраивается. Они не только сборщики js но и всего что есть в вебе. Нужен бабель — в доке указано как.
Осталось поведение мудаков типа FF, Safari типа использования
import конструкций внутри воркеров.
wpt.fyi/results/workers/modules/dedicated-worker-import.any.html?label=master&product=chrome%5Bstable%5D&product=firefox%5Bstable%5D&product=safari%5Bstable%5D&product=chrome%5Bexperimental%5D&product=firefox%5Bexperimental%5D&product=safari%5Bexperimental%5D&aligned
Такие кейсы, по-моему, умеет полифилить только вебпак. То есть он может обернуть (с бабелем или нет — не знаю) современные импорты в воркерах в несовременный importScripts() но зато везде рабочий.
неприятно так попадать! Везде уже es6 модули как recommended стоят, а в воркерах бах, рано, юзай синхронный importScripts()
Так можно же запилить мультиплексирование, если не на уроне транспорта http2 (если там действительно накладные расходы), то на уровне js загрузчика и специализированного серверного компонента. Я еще 10 лет назад носился с динамическим импортом с мультиплексированием, но тогда нормально не удавалась решить одну проблему- кеширования модулей, из-за отсутствия Cache API и мизерного объема LocalStorage для его эмуляции в 5мб, который весь занимать и нельзя, к тому же он еще тогда не везде был. А модульного кода не было так много, так что захейтили подход.
Конечно бандлится в прод.
TS-код всегда можно проверить одной командой:
npx tsc --noEmitДля работы нужно установить NPM-пакет typescript. Запускайте команду в корне проекта где лежит tsconfig.json.
Vite сырой ещё для чуть не типичных задач. Например, он не включает в бандл воркеры которые заданы через стандартный es6 new Worker. Ему нужно import worker from .. он не вытягивает все зависимости из подключенной сторонней библиотеки. Postcss с деприкейтнутым синтаксисом.
Магия и эвристика поиска зависимостей мне не понятна. Я не понимаю как vite тянет зависимости.
Но мне vite очень нравится
Грубо говоря, main.ts превращается в main.js и отдаётся браузеру. В main.js делается `import { a } from 'a.ts'`, браузер знает про es6 модули, поэтому отправляет запрос на получение a.ts, а dev-сервер vite, который висит на 3000-м порту, понимает, что перед выдачей a.ts надо его переделать в js.
У меня вместо встроенного PostCSS отдельный скриптик запускается, который в сторонке собирает SCSS в CSS.
Про воркеры не знал, спасибо.
Сидел недавно ждал 2 мин прод сборку и думал, что там можно делать с моими 20-тью файлами и из зависимостей Vue+Vuex?
5 вещей, которые я узнал, доведя Snowpack до 20000 GitHub-звёзд