Comments 29
Где тогда описание использования утилиты в команде и т.п.?
Использование в команде на текущем этапе не сильно отличается от индивидуального использования. Когда добавим его в наш CI, то, конечно, новые интересные вещи появятся. Но там всё более-менее прозрачно.
Естественно должны быть хуки. Но читайте внимательнее — это будет чуть дальше. На текущий момент нужно было хотя бы дать разработчиком возможность использовать сам линтер. Хотя бы чтобы было время спокойно отрефакторить код до добавления хуков — а не блокировать всю разработку тем, что внезапно код перестал уходить в репозиторий.
Вы уж меня простите, но вы там командой чтоли лендинги какие-то пилите? В 2017 году без таск-раннеров и линтинга со старта это жесть какая-та.
В любом нормальном проекте линтер должен прогонятся после каждого изменения кода, + обязательный прогон перед пушем (вместе с тестами), чтобы не пропустить никакую фигню. И для такого не обязательно иметь большую и серьезную команду, уже с двумя разработчиками жизнь без таких вещей превращается в ад.
А отсутствие линтера обусловлено банальным наследованием легаси и большой загрузкой. Вернуться в прошлое и добавить линтер, к сожалению, не представляется возможным. Новые проекты, естественно, стартуют уже с линтером.
Не понял часть про PCI DSS: зачем соблюдать PCI DSS на тестовых серверах, и еще зачем для этого все шифровать? Прошу прощения за такой вопрос, мои знания о PCI DSS очень поверхностные.
А шифровать для PCI DSS зачем все? Я по диагонали читал материалы о PCI DSS, но там вроде о тотальном шифровании кода и всех зависимостей вообще не говорится. Или я пропустил, это все такая занудная и плохо структурированная тема, читал скорее для общего развития, чем из необходимости.
А с ростом объёма зависимостей мы успешно боремся. Со временем их становится меньше.
Правда коллеги приводят довод, что если какой аврал будет, то из — за этого линтера не получится в срочном порядке вылить изменения на прод, а я фыркаю на них…
Бывшие C#-овцы. Используем TypeScript и TSlint и горя не знаем. И вам рекомендуем. :)
А для прогона кода между серверами у нас гит с https.
Если вы гоняете автотесты на престейбле, то возможно логичнее выделить тестраннер в отдельный пакет, и все его зависимости перенести в dependency этого пакета. Это должно сэкономить вам еще драгоценное место.
devDependency как мне кажется должны использоваться для другого. В рамках продакш пакета это то место, где вы можете позволить себе указывать неточные версии модулей, потому что знаете, что эти модули не утекут в продакшн.
К слову, если вы заботитесь о надежности сборки пакета, то наиболее надежным подходом будет установка через shrinkwrap из локальной директории. В этом случае вы сможете выкатить хотфикс, даже если npm сломан.
Выделять тесты в отдельный пакет, который будет в отдельном проекте и репозитории — это нарушать целостность кода. Кроме того, если мы его ставим как devDependency, то он прилетает со всеми своими вложенными devDependency.
В данном случае я не предлагал вам уносить тесты из проекта, только тестраннер.
Предположим вы используете какой-нибудь стандартный стек тестирования (karma + mocha + chai + istanbul) для project.
Хотя, раз речь идет о микросервисах, вероятно вы обходитесь без karma.
Определенно именно такая связка у вас должна запускаться в dev окружении. Но в продакшн вам не нужен istanbul, а значит и устанавливать его не имеет смысла.
Создаем еще один пакет project-testrunner и собираем у него в зависимостях все, что нужно для тестирования в продакшн.
Для project прописываем в некотором postinst (уж не знаю, какие именно у вас пакеты):
# Плохой пример поиска пакета. Лучше поставить этот пакет как глобальный npm модуль.
if [ -d ../project-testrunner ]; then
../project-testrunner/bin/test project/test
else
echo "Осмысленная ошибка о том, что пакет тестраннера не установлен на машину"
fiТ.е. мы все так же прогоняем тесты над директорией project/test, но делаем это с помощью внешнего пакета.
Для dev мы можем указать project-testrunner как devDependency и запускать например так:
#package.json
"devDependencies": {
"project-testrunner": "*"
},
"scripts": {
"test": "project-testrunner ./test --coverage"
}Конечно придется ручками написать скрипт testrunner, но это всяко лучше, чем использовать peerDependency не по назначению.
При этом istanbul можно указать как devDependency для project-testrunner
Насчёт зависимостей для тестов — есть ещё одна хорошая issue, в которой предлагают ввести секцию testDependencies, что имхо правильно, но пока что документация по package.json говорит о том, что тесты должны быть в devDependencies.
"lint": "./node_modules/eslint/bin/eslint.js app.js routes modules test App.js"
Лучше написать так:
"lint": "eslint app.js routes modules test App.js"
Сложно о простом: ESLint в команде