Ура-ура! Мой доклад про webpack с HolyJS выложили в открытый доступ 🎉
https://youtu.be/qKz9YAeKYMs

Наверное мало кто знает, но в Статоскопе можно составлять свои собственные отчеты по статам и потом делиться этими отчетами с коллегами. Я обязательно расскажу об этом в статье на хабре.
Так же, Статоскоп умеет обрабатывать несколько файлов со статами. В этих файлах может быть информация как об одной компиляции, так и о нескольких сразу (например, если вы в одной сборке собираете и клиент и сервер).
Проблема здесь в том, чтобы структура статов всегда была единой вне зависимости от их содржимого, ведь если я с каждым релизом буду ее менять, то ваши кастомные отчеты будут ломаться с той же частотой.
Сейчас я практически стандартизировал структуру статов и готовлюсь к релизу

Сейчас остановился на такой структуре.

Друзья, всех с первым днем зимы и третьей версией Статоскопа!
Statoscope 3.0 опубликован! 🎉
Почему 3.0? Я очень сильно поменял структуру статов, в которую в итоге превращаются json-файлы, поэтому это мажорный апдейт.
Если коротко, то список изменений такой:
- Сравнение сборок 🚀
- Теперь можно загружать несколько файлов и переключаться между ними
- Поддержка проектов с мультиконфигом
- Переработан дашборд на главной странице
- Добавлен поиск модулей с идентичным исходником
- Переработан Readme на github 😉

Полный список изменений можно посмотреть в changelog.
Ну а сам Статоскоп, как обычно - https://statoscope.tech

Следующие шаги:
- Написать статью на Хабр, чтобы о Статоскопе узнало как можно больше людей
- Внедрить потоковый парсер JSON-статов чтобы снять большинство ограничений на размер статов (Роман Дворнов очень подробно описывает пропроблему в своем канале и рассказывает как решает ее)
- Реализовать интеграцию Статскопа с CI

И, как обычно, если видите какие-то недочеты в работе Статоскопа, или у вас просто есть идеи по его улучшению, то смело заводите issue на github 😉
Можно даже поиграть в такую "игру". Пусть каждый кто прочитат этот пост, задаст себе вопрос: "А что я хочу узнать о моем бандле?"
Свои ответы присылайте в комменты к этому посту или сразу заводите issue 😉
Буду очень благодарен за это!

P.S.: Если вы инженер или компания, зантересованная в развитии Статоскопа, то вы можете поддержать Статоскоп на OpenCollective 😉

Друзья, опубликован Statoscope 3.2.0 в котором добавился полноценный webpack плагин.
К сожалению, не все хотят/могут загружать свои статы на внешний ресурс (https://statoscope.tech), и хотя загружаемые статы нигде не хранятся и остаются исключительно в вашем браузере, множество людей ограничены NDA, что не позволяет им загружать что-либо на неизвестные ресурсы.
В любом случае, теперь ничего никуда загружать не нужно, просто подключите webpack-плагин, который сохранит один единственный HTML с отчетом и автоматически откроет его после завершения компилции.
const StatoscopeWebpackPlugin = require('@statoscope/ui-webpack');

config.plugins.push(new StatoscopeWebpackPlugin());
Приятного использования 😊

Эксперементирую с поточным JSON-парсером, который пилит Роман Дворнов
Только что удалось запихать в Статоскоп статы размером в 1 ГБ (напомню, что сейчас макисмальный размер статов составляет 512mb, из-за ограничения на длину строки в движке V8)
Чуть позже расскажу что и как пришлось подшаманить и почему даже с поточным парсером не все так просто 😉

Друзья, опубликован Statoscope 3.3.0
Теперь он поддерживает статы любого размера, а еще, теперь можно указать список статов для сравнения прямо в плагине
Полный список изменений тут https://github.com/smelukov/statoscope/releases/tag/v3.3.0

https://github.com/webpack-contrib/webpack-bundle-analyzer/issues/406
А почему бы и нет 😉

Друзья, поздравляю вас с Новым Годом! 🎄
У меня, как всегда, много планов и целей на этот год и очень скоро я сделаю очень важный для меня анонс. И пусть в новом году у всех нас все наши планы реализуются 🚀

Привет! Исследую одну, как мне кажется, интересную тему - определение неиспользуемых ветвей в больших объектах. Это может пригодиться, например, для анализа стейта вашего приложения с целью определить какая часть стейта является избыточной для вашего приложения, чтобы не присылать ее на клиент.
Я вижу здесь два варианта реализации: статический анализ и анализ в рантайме.
Хочу узнать что думаете и может встречали какие-то готовые решения ☺️
PS: реализовал свое решение, чуть позже расскажу

Немного подбробнее раскрою тему, которую начал выше.
Понять какие части объекта используются, а какие нет, надажнее всего через рантайм. Статический анализ не всегда помогает:
- код можно написать так, что его довольно сложно будет проанализировать статически
- не поможет в кейсах, когда обращение к свойствам в коде есть, но фактически этот код мертвый и до него дело никогда не доходит (ранее писал большой пост про DCE)

Итого, искать неиспользуемые куски объекта лучше в рантайме. В плане реализации, нужно перехватывать все попытки обратиться к любым свойствам объекта, даже к тем свойствам, которых еще нет. При попытке обратиться к свойству - фиксруем эту попытку и в нужный момент извлекаем инфрмацию о usage coverage (какие ветки используются, а какие нет).
Для этого можно использовать Proxy, что я собственно и сделал и запилил для этих целей библиотечку Gettie.
При помощи Gettie можно обернуть любой объект и следить за попытками доступа с его свойствам (без ограничения глубины).
Почитайте описание, посмотрите демку, попробуйте сами и поделитесь мыслями/идеями ☺️
Смысл демки в том, в у каждой todo в стейте приложения есть два заведемо неиспользуемых поля: createdTS и editedTS
Создавая/редактируя todo-шки, нажимайте на Refresh и смотрите как растет количество неиспользуемых веток в стейте.

Статистику можно собирать двумя путями:

1) Оборачивать стейт в рамках А/Б тестирования, например, собрать статистику только с 1% пользователей
Более правдивые результаты. И чем на больший % раскатываем - тем более правдивые результаты получаем.
Минус такого подхода - импакт по производительности клиента из-за постоянных оберток (зависит от размера стейта и частоты обращений к нему)

2) Собирать статистику во время e2e-тестов
Менее правдивые результаты, т.к. e2e-тесты лишь эмулируют поведение пользователя

🎉 Замержили мой PR в вебпак, который добавляет возможность очищать содержимое выходной директории перед сборкой:
{ output: { clean: true } }
Эдакая замена WebpackCleanPlugin

Всем привет! В блоге Яндекса на Хабре я опубликовал свои мысли по поводу типизации и ее применимости к JS
https://habr.com/ru/company/yandex/blog/541338/
Делитесь своими мыслями в комментах, приятного чтения ☺️

А еще, я ищу JS-разработчиков, прямо в мою команду инфраструктуры фронта 🚀
Если для вас это актуально, то присылайте резюме в личку ☺️
https://yandex.ru/jobs/vacancies/dev/front_develop_market/
https://yandex.ru/jobs/vacancies/dev/nodejs_market/

Привет! Небольшая заметка о том, как я затаскивал поддержку больших статов в генерируемые Статоскопом HTML-отчеты.
Как мы с вами уже знаем, у JS-движков есть ограничение на максимальный размер строки (например 512мб для V8)
Это значит, что при попытке получить строку большего размера, мы получим ошибку RangeError: Invalid string length
Очевидно, что для статов размером больше 512mb тот же JSON.parse работать не будет, но как раз JSON.parse нам и нужен.
Обойти ограничение можно при помощи поточного JSON-парсера. Такому парсеру нужен источник строки, который будет отдавать ее не целиком, а кусочками (например по 64кb). По мере того, как парсер получает кусочки, он пытается их распарсить - превратить в объект. Очевидно, что этот объект растет по мере парсинга. Смысл в том, что мы не обрабатываем большие строки, а следовательно, у нас не возникает исключения RangeError, а сам объект путь себе растет пока хватает оперативной памяти.
Ну хорошо, делаю первый подход - взял поточный парсер от @rdvornov, формирую HTML и инъекчу в него код вроде такого:

const chunks = [
  сюда вставляю большой JSON порубленный на строки по 64kb
];
const data = await jsonExt.parseChunked(() => chunks);
Statoscope(data);

Запускаю - не работает, браузер просто зависает 🤔
Методом проб и ошибок выяснил, что бразуер просто не переваривает такой большой тег скрипт (несколько сот мегабайт). Никакой особо полезной информации я по этому ограничению не нашел, но стало ясно, что теперь я воткнулся в проблему лимитов самого браузера. Стал думать что здесь можно сделать. Пришла идея попилить на куски не только JSON, но и теги noscript:

<noscript>
  chunks.push(КУСОК_JSON)
</noscript>
<noscript>
  chunks.push(СЛЕДУЮЩИЙ_КУСОК_JSON)
</noscript>

..... здесь еще много подобных тегов noscript

<noscript>
  const data = await jsonExt.parseChunked(() => chunks);
  Statoscope(data);
</noscript>

Запустил, заработало! Теперь я смог обойти и ограничение на JSON.parse и ограничение браузера на размер тега noscript.
Учитывая то, что загружать в отчет можно сразу несколько файлов со статами, например, для сравнения сборок, предусмотрел пуш чанка по идентификатору стата:

<noscript>
  api.pushChunk("stat1.json", КУСОК_JSON)
</noscript>

<noscript>
  api.pushChunk("stat2.json", КУСОК_JSON)
</noscript>

<noscript>
  api.pushChunk("stat1.json", КУСОК_JSON)
</noscript>

Таким образом даже не важен порядок, в котором статы сбрасываются в отчет.

Прошло какое-то время и @rdvornov задал интересный вопрос: "Слушай, а почему бы не использовать теги noscript не как скрипт, а как текст, тогда можно было бы сэкономить на парсинге?"
И действительно, если сказать браузеру, что содержимое noscript - это не скрипт, а текст, то браузер не будет тратить время на парсинг сожержимого. А, на минуточку, 64kb x Nk тегов noscript - это ощутимо.

В итоге получилось что-то вроде:

<noscript type="text/plain" data-id="stat1.json">КУСОК_JSON</noscript>
<noscript type="text/plain" data-id="stat1.json">КУСОК_JSON</noscript>

......

<noscript>
  for (const element of document.querySelectorAll('noscript')) {
    api.pushChunk(element.dataset.id, element.textContent);
  }

  const data = await jsonExt.parseChunked(() => api.getChunks());
  Statoscope(data);
</noscript>

Там конечно чуть сложнее, полную версию изменений можно посмотреть тут

Итог этой простой манипуляции такой: время загрузки отчета со статами в 650mb сократилась с 21 секунды до 14 (профит в 33%!!!)
Мораль: почти всегда можно что-то придумать, чтобы стало лучше (даже когда кажется, что нельзя) 😉

Выпустил Statoscope 3.5
Туда вошло изменение, ускоряющее получения списка npm-пакетов и их инстансов https://github.com/smelukov/statoscope/pull/43
Это значительно уменьшило время генерирования отчета при помощи плагина.
Кстати, это первый сторонний ПР в Statoscope, который что-то улучшает 🚀

А еще, видимо что-то пошло ТАК и Statoscope начали использовать на CI, т.к. количество скачиваний резко возросло https://npm-stat.com/charts.html?package=%40statoscope%2Fui-webpack 🤘🏻
Хотя, если вы большой проект, то лучше использовать кеширующий npm-proxy, например Verdaccio

Привет!
Году в 2017 я залип на соревновании return true
Вам дается функция, нужно изучить исходный код и понять что нужно передать в функцию в качестве аргумента так, чтобы функция вернула true.
Проблема в том, что задание нужно не просто решить, а сделать это за минимальное количество символов.
Есть простые задания, а есть и зубодробительные.

Я тут раскопал свои решения из первого сезона соревнования, но с тех пор вышло много других задач.
Интересно было бы видеть тут разбор этих задачек с моими размышлениями и комментариями? В виде ссылок на статьи в телеграфе (чтобы не спойлерить тем, кто хочет решить все сам)

27 февраля пройдет конференция Я Люблю Фронтенд и в рамках конференции был запущен челледж в формате Capture The Flag
Прошел где-то за 3.5 часа ✅
Рекомендую, помогает встряхнуть мозг 😉

https://www.joinclubhouse.com/event/M1zov8YL
Сегодня в 19:00 по МСК мы с коллегами будем болтать про сборку и отвечать на вопросы, подключайтесь ;)