Читатели задают вопросы о том, что делает ~~(number / 10). Давайте разбираться, ведь одна из целей разборов этих задач - узнать что-то новое.

Оператор ~ - это "побитовое НЕ", он инвертирует биты числа на противоположные: 10101 -> 01010.

Итак, зачем это всё? Дело в том, что побитовые операции можно производить только с целыми числами, поэтому при попытка применить побитовые операции к числу с плавающей точкой, дробная часть будет отброшена и это дешевле нежели использовать Math.floor и т.п.

Тут встает вопрос в том, какой побитовый оператор использовать, ведь каждый их них как-то модифицирует число. То есть применив побитовый оператор, мы так или иначе модифицируем число, а значит нам нужно применить такой оператор, чтобы биты числа можно было восстановить в их изначальный вид. Таким оператор как раз является ~:

10101 -> 01010

А теперь, если мы снова применим этот оператор к получившемуся числу, то получим изначальный порядок бит:

01010 -> 10101

Таким образом мы очень дешево избавились от дробной части при помощи битовых операций, не повредив само число.

Завел несложный issue в Статоскоп и пометил его тегом Good for contribution
Такие задачки можно смело брать в работу если хочется поконтрибьютить 😉
Если берете себе задачку, отмечайте себя
В будущем буду еще заводить 😉

Привет!
Вышел Statoscope 4.0 📦
Накопилось 😊

- Ломающее: Удалена сборка с отдельными стилями. Теперь Статоскоп - это изолированный монолит и все его стили встроены в единый бандл.

- Добавлена обработка дочерних комиляций
Теперь Статоскоп показывает информацию о дочерних компиляциях. Например, если вы собираете проект с веб-воркерами, то веб-воркеры собираются дочерней компиляцией и теперь Статоскоп показывает информацию о таких компиляциях.
По умолчанию такие компиляции скрыты, но при помощи настройки Hide child compilations в UI, вы можете это изменить.

- Теперь Статоскоп показывает не просто размер чанка, а отдельно, размер чанка и размер ассетов, связанных с этим чанком (это тот самый issue, который я создавал для того, чтобы вы могли поконтрибьютит в Статоскоп, спасибо пользователю с ником immitsu на гитхабе).

- Обновил версию DiscoveryJS (спасибо @rdvornov)

- Обновил стек сборки самого Статоскопа

- Обновил Foam Tree

Так же хочется сказать спасибо @iamakulov и @vladkorobov за поддержку Статоскопа 🙏

PS: Впереди много планов на то, какие задачи должен решать Статоскоп и как именно он это будет делать. Оставайтесь на связи

Привет! Ох и летит время... Последний пост был ровно месяц назад 😅
Со мной все хорошо, просто стало больше проектов на работе.
Сегодня я подвез вам релиз Статоскопа 4.1.
Теперь Статоскоп стартует на 25% быстрее (за счет оптимизации логики нормализации данных), а еще в разы улучшил скорость сравнения статов. Статы, которые раньше сравнивались за 25 секунд, теперь сравниваются за сотни миллисекунд.
Как только появится чуть больше свободного времени, Статоскоп ждет большой рефакторинг с целью декомпозировать его на разные независимые части. Это позволит наконец покрыть его тестами и реиспользовать логику анализа статов в разных окружениях (например в CLI на CI). А еще, я буду пробовать внедрять собственный универсальный формат статов (не webpack-specific). Это позволит в разы уменьшить потребление ресурсов при обработке статов и размер самих статов.

P.S.: Спасибо пользователю с ником TchernyavskyD за поддержку Статоскопа на OpenCollective 🙏

Друзья, я выпустил Statoscope 5.0
Главная фича этого релиза в том, что статоскоп наконец может работать как CLI-инструмент 🎉

statoscope serve stats.json
Поднять HTTP-сервер с HTML-отчетом по указанным статам (можно указать несколько и тогда они будут объеденены)

statoscope generate stats.json report.html
Сгенирировать HTML-отчет из статов (можно указать несколько и тогда они будут объеденены)

И на десерт киллер фича - провалидировать статы (или разницу в статах):
statoscope validate rules.js stats.json

Супер полезно на CI.
Примеры можно посмотреть в README

⚠️ Важно: пакет @statoscope/ui-webpack был распилен на 2:
- @statoscope/webpack-plugin
- @statoscope/webpack-ui
Если вы использовали статоскоп как webpack-плагин, то юзайте пакет @statoscope/webpack-plugin
Api не изменилось ☺️

В этом релизе я был сконцентрирован на декомпозиции большого пакета ui-webpack на несколько мелких.
Так же у статоскопа теперь своя github-организация.

Дальше будет переезд на TS и покрытие тестами. А еще дальше буду пробовать собственный формат статов и двигать его в массы, так сказать :)

А еще, хочу уделять больше времени написанию технических постов (давно ничего не писал, исправлюсь)

Всем привет!
Я наконец написал технический пост на тему внутренного устройства Statoscope - https://medium.com/@smelukov/метаинформация-о-сборке-5469a7ab6aa4
Заходите, читайте, комментируйте, задавайте вопросы ☺️

Ох, как интересно, в webpack 5.49 можно импортировать http-модули 🚀
Импортированные модули кладутся в локальный кеш, поддерживается его обновление. Консистентность обеспечиваешь хешиком(как в package-lock)

Пример из директории examples

Доступно под флагом experiments.buildHttp

Кстати, если есть желание почитать про TS что-то кроме официальной документации, то могу порекомендовать книжку Профессиональный TypeScript. Разработка масштабируемых JavaScript-приложений
Помогает структурировать, уложить и закрепить знания

Хочу поделиться с вами супер-крутой и секретной штукой, которая будет добавлена в Статоскоп уже вот-вот.
Это валидация статов на основе правил. Это похоже на eslint, но для статов и с дополнительными плюшками. Есть конфиг, в котором вы перечисляете правила, которые хотите применить к сборке и есть cli-команда statoscope validate которая помимо консольного отчета о валидации, сгенерит вам привычный Статоскоп отчёт + супер-классный и подробный отчёт о валидации прямо в UI статоскопа. Незаменимо в CI.
В наборе уже есть основные правила, например, для бюджетирования времени/размера скачивания бандов, для запрета использования определенных модулей, для определения того, увеличилось ли время/размер скачивания по сравнению со статами, например в мастере и тд.
А ещё, можно писать свои правила и кастомные view для них.

Пока это самая непростая история в Статоскопе. И даже не с точки зрения реализации, а с точки зрения удобства. Негде подсмотреть, поэтому приходится изобретать, тк действительно очень много нюансов

Друзья, я вновь выступаю на HolyJS 🎉
На этот раз я займу целых 2 слота, первый - доклад про Statoscope и его архитектуру, а второй в формате workshop, на котором мы попробуем расширить Statoscope, написать свои кастомные отчеты, правила для валидации и view к ним, посмотрим на инструмент изнутри 🚀
На самом деле это будет главный публичный анонс Statoscope на широкую аудиторию и я действительно долго к этому шел :)

Сегодня не просто день знаний, а день знаний о вашем бандле 😁
Встречайте Statoscope 5.7 с новой концепцией валидаторов 🎉
Теперь вы можете следить за тем, чтобы, например, время сборки вашего бандла или загрузки бандла у клиента не привышали определенного вами лимита. И все это можно делать прямо на CI, таким образом не давать возможность замержить ПР который ухудшает вашу сборку.

Валидация осуществляется на основе правил. Конфигурация правил очень похожа на то, как это сделано в eslint.
В корне проекта достаточно создать файл statoscope.config.js, например, с таким содержимым:

module.exports = {
validate: {
plugins: ['@statoscope/webpack'],
rules: {
'@statoscope/webpack/build-time-limits': ['error', 10000],
'@statoscope/webpack/restricted-packages': ['error', ['lodash']],
'@statoscope/webpack/no-packages-dups': ['error'],
'@statoscope/webpack/entry-download-time-limits': ['error', {
network: 'Fast',
global: { maxInitialDownloadTime: 1000 }
}],
},
},
};

И затем запустить команду
statoscope validate --input="path/to/stats.json"
Это позволит убедиться в том, что ваша сборка соотвествует описанным правилам, а именно:
- собирается не больше 10 сек
- не использует пакет lodash
- не имеет дублей пакетов
- initial-ассеты на страницах загружаются не более чем за 1 сек

А можно еще сравнивать статы между собой с помощь специальных правил:

module.exports = {
validate: {
plugins: ['@statoscope/webpack'],
rules: {
'@statoscope/webpack/diff-build-time-limits': [
'error',
{ global: { type: 'percent', number: 10 } }
],
'@statoscope/webpack/diff-entry-download-time-limits': [
'error',
{ global: { maxInitialDownloadTimeDiff: 1000 } },
],
'@statoscope/webpack/diff-deprecated-packages': ['error', [/rxjs/]],
},
},
};

И затем запустить команду
statoscope validate --input="path/to/branch.json" --reference="path/to/master.json"
Это позволит убедиться в том, что в сборке из текущей ветки:
- время сборки увеличилось не более чем на 10%
- время скачивания initial-ассетов на страницах увеличилось не более чем на 1 сек
- количество использований пакета rxjs не увеличилось

Конечно же, правила можно миксовать между собой как угодно.

Всего есть 12 правил. Полный список и документация есть по ссылке

Ну и киллер-фича всего это мероприятия - UI-отчет о результатах валидации.
Достоточно добавить специальный репортер в конфиг, чтобы после валидации статов открылся Discovery-отчет в котором помимо прочего будут содержаться результаты валидации.

module.exports = {
validate: {
plugins: ['@statoscope/webpack'],
reporters: ['console', ['stats-report', { open: true }]],
rules: {
....
},
},
};

Если вам интересно поконтрибьютить или придумать свои правила/репортеры и т.д., то милости прошу в документацию по валидатору, где описаны основные концепции

А кто-нибудь уже пробовал новый валидатор, правила и особенно UI-отчёт? Поделитесь пожалуйста фидбеком ☺️

На сколько эффективен формат статов вебпака?
Ужасно неэффектифен, потому что данные в статах денормализованы (почти).

Из-за этого, отчет со сравнением и валидацией сборок фиче-ветки и мастер-метки может занимать 4-5 гб (в нашем случае было именно так).
Это делает проблематичным просмотр отчета, потому что HTML очень большой. Супер-классный парсер от Романа Дворнова его спокойно прожует, а вот браузер уже с трудом и в зависимости от ресурсов вашего устройства, вкладка либо будет очень долго открываться, либо будет бесконечно крашиться, ну и места такой отчет на CI займет не мало, на каждый ПР. В результате чего к вам могут прийти ваши DevOps с вопросов вроде "Вы что, используете наш CI как хранилище фильмов? 😑"

Сегодня ночью я решил эту проблему и UI-отчет теперь очень сильно уменьшился в размере.
Например, отчет на 4-5 гб уменьшился до 250мб (в 15 раз!) и открывается за 15 секунд (от момента когда браузер запустился, до момента когда уже можно смотреть отчет).

Это стало возможным благодаря нормализации статов вебпака до того как записать их в отчет.
Грубо говоря, я составил карту всех возможных модулей в статах, вынес их в отдельное служебное поле статов и заменил места их использования порядковыми номерами. В просмотрщике отчетов я сделал обратное преобразование и.... собственно всё 🙂

Кстати, статы вебпака неспроста денормализованы.
Дело в том, что каждый чанк содержит информацию о модулях внутри него и если одни и те же модули используются в разных чанках, то они будут продублированы в статах для каждого чанка, с небольшими отличиями, например, поле chunks в модуле, который находится в чанке foo, будет равно ["foo"]. И так для каждого чанка, внутри которого содежрится этот модуль. А если у вас сотни чанков и тысячи модулей? 😉
В итоге я решил просто помержить содержимое полей chunks от одних и тех же модлей в разных чанках, таким образом получив один модуль, который содержит инфо о чанках, в которых он используется и это ничего не ломает.

ПР можно посмотреть тут, а changelog релиза 5.8.0 здесь

Reddit - странное место. Я часто думаю о том, чтобы продвигать Статоскоп за пределами СНГ. Так, например, я закинул пост-анонс Статоскопа на dev.to и Reddit (в сообщество webpack)
Зашёл через 15 минут в свой пост на реддите и вижу надпись «удалено» 🤔
Пишу в поддержку, спрашиваю «как так-то?». Получаю ответ:
- Ваш пост был удалён администратором сообщества с пометкой «спам», можете попробовать написать админу сообщества, но он не обязан вам отвечать
🤦‍♂️
Я написал администратору сообщества, объяснил ситуацию, объяснил, что это не спам, а мой опенсорсный проект, который приносит пользу и я хочу рассказать о нем как можно большему количеству людей.
Администратор сообщества до сих пор мне не ответил и пост мой так и не вернули. А было там вот это https://dev.to/smelukov/brand-new-toolkit-to-analyze-and-validate-your-webpack-bundle-456p
Скорее всего никогда больше не пойду на реддит делать какие-то анонсы (в сообщество webpack уж точно)
Сижу вот, думаю, может на какой-нибудь заграничной конфе выступить :)

В 12:45 рассказываю на Я.Субботнике про Statoscope ☺️
https://events.yandex.ru/events/yasubbotnik/18-sep-2021

Вчера, видимо по следам моего доклада, в Statoscope занесли ПР. Спасибо!
Интересно, что GitHub теперь показывает участников релиза, если упомянуть их в описании релиза ☺️

Ребята из подкаста Ленивый Фронтендер позвали меня поболтать про Statoscope 28 сентября в прямом эфире на YouTube ☺️
Анонсирую там новую фичу и насыплю технических деталей ☺️
Все таки архитектурное решение с расширением статов даёт свои плоды 🚀

PS: Во всю готовлюсь к воркшопу на HolyJS, вот там действительно будет вал технических деталей 😉

#14 Ленивый фронтендер | Bundle inside

В новом выпуске Сергей Мелюков, автор Statoscope, поделится с нами деталями разработки, историей возникновения проекта, дальнейшем развитии и многом другом!

Statoscope – это инструмент для детального анализа webpack-бандла.

Стрим начнется 28.09 в 18:30 (GMT+3) и будет доступен на Twitch и YouTube.

Вот-вот начнём 😀

https://www.youtube.com/watch?v=gSC9T6w8ygc

А вот и фича которую я обещал анонсировать в подкасте, но на всякий случай продублирую здесь.
Теперь можно создавать кастомные отчёты и пробрасывать прямо в UI.
Прямо сейчас примеры можно посмотреть на https://statoscope.tech (выбрать демо-статы и сверху справа будет выпадашка “Custom Reports”
А посмотреть пример использования можно здесь.
В чем смысл: вы можете передать в конфиг плагина массив из кастомных отчетов, которые будут проброшены в UI-отчёт.
Каждый элемент массива это объект с несколькими полями:
- id - идентификатор отчета
- name - отображаемое имя
- data - данные с которыми будет работать отчёт. Это могут быть как заранее известные данные, так и функция, которая куда-то за этими данными идёт и возвращает промис
- view - вью на DiscoveryJS (можно использовать композицию из готовых компонентов)

Во view можно передать как JSON, так и строку.
И если с JSON все понятно, то вот со строкой интересно.
Пока у вас простой отчёт, вы можете обойтись JSON-ом, а когда вам понадобится более сложный интерактивный отчёт (с обработкой кнопок и других событий), то сразу встанет вопрос - а как собственно передать код функций-обработчиков в виде JSON? Ответ - никак 🙂
Вместо этого, во view можно передать строку, которую Statoscope UI заэвалит (eval) и которая в результате должна вернуть DiscoveryJS view.
Например:
{
id: “foo-report”,
view: fs.readFileSync(“my-report.js”, “utf8”)
}

Тут конечно встаёт вопрос безопасности, потому что этот код будет выполняться на браузере у клиента, а нам не всегда хочется чтобы в нашем браузере выполнялся какой-то непонятный произвольный код, особенно если он получен непонятно от кого (вам ведь могут просто прислать HTML-отчёт статоскопа, мол, «посмотри пожалуйста».
Я решил, что в тех случаях, когда в качестве view передаётся строка, перед отображением отчета отображается предупреждение-вопрос, мол, "Вью этого отчета - это скрипт. Вы доверяете источнику отчета и согласны выполнить этот скрипт?"
Посмотрите пример.
Всё это счастье работает на все том же механизме расширения статов и под кастомные репорты есть свое расширение.