Монорепо — это (хорошая|плохая) стратегия? Честно говоря, мне все равно. Но я понял, что часто использую его при разработке проектов NodeJS+React.
Когда я выполняю автоматический статический анализ кода в монорепозитории, всегда возникают две основные проблемы: покрытие и шаблоны кода.
Что касается охвата, то ответ довольно прост: Codacy позволяет создавать частичные отчеты как для бэкенда, так и для фронтенда. Это задокументировано здесь и выглядит примерно так:
➜ ~ codacy-coverage-reporter report -l javascript -r server_report.xml --partial ➜ ~ codacy-coverage-reporter report -l javascript -r client_report.xml --partial ➜ ~ codacy-coverage-reporter final
В главе Шаблоны кода это всегда будет зависеть от линтера. ESLint — это де-факто утилита линтинга для JavaScript, и, поскольку у нее есть множество полезных плагинов (да, и для безопасности), я использую именно ее. Само по себе это не решает моей проблемы с наличием двух разных проектов в одном репозитории. К счастью, есть способ:
В папке src моего проекта я обычно создаю папку client и server. И здесь имеет смысл иметь файл .eslintrs.js. В этом файле можно задать общие правила или даже оставить пустым
[repo]/src/.eslintrc.js
module.exports = {
}
Затем в каждую папку клиента или сервера можно добавить дополнительный файл .eslintrc.js, расширяющий файл src, переопределяющий правила, определенные ранее.
[repo]/src/client/.eslintrc.js
module.exports = {
"extends": "../.eslintrc.js",
rules: {
quotes: [2, "single"]
}
}
[repo]/src/server/.eslintrc.js
module.exports = {
"extends": "../.eslintrc.js",
rules: {
quotes: [2, "double"]
}
}
Локально, похоже, все идет так, как ожидалось. Теперь в Кодаси! На вкладке Шаблоны кода я выбрал Файл конфигурации вместо правил из пользовательского интерфейса.
И получили точно такие же и ожидаемые результаты.
Стратегия монорепо может быть спорной, но никогда не будет проблемой.
