Сложно о простом: ESLint в команде

В данном случае я не предлагал вам уносить тесты из проекта, только тестраннер.

Предположим вы используете какой-нибудь стандартный стек тестирования (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

Сложно о простом: ESLint в команде

Мне не совсем понятна ваша проблема с devDependency. Правильно ли я понимаю, что в продакшн у вас улетает пакет со всем, что лежит в dependency и devDependency? Если так, то это достаточно странно.

Если вы гоняете автотесты на престейбле, то возможно логичнее выделить тестраннер в отдельный пакет, и все его зависимости перенести в dependency этого пакета. Это должно сэкономить вам еще драгоценное место.

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

К слову, если вы заботитесь о надежности сборки пакета, то наиболее надежным подходом будет установка через shrinkwrap из локальной директории. В этом случае вы сможете выкатить хотфикс, даже если npm сломан.