Сергей Мелюков

Сегодня не просто день знаний, а день знаний о вашем бандле 😁
Встречайте 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: {
....
},
},
};

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

GitHub

Release v5.7.0 · statoscope/statoscope

Features

[stats-validator] - add package for validating stats
[stats-validator-plugin-webpack] - add stats-validator plugin with webpack-rules
[stats-validator-reporter-console] - add stats-valida...

www.tgoop.com/smelukov_dev/93

1.48K viewsСергей Мелюков, edited  Sep 1, 2021 at 13:51

Сегодня не просто день знаний, а день знаний о вашем бандле 😁
Встречайте 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: {
....
},
},
};

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

BY Сергей Мелюков