LINT: (Feedback) Refine bootstraping of linting
azinit opened this issue · comments
Problem
- Redundant TS settings
alwaysTryTypes
? - Too much dependencies to install
- Too much steps to do for quick setuping of linting
Reference
Сегодня весёлое настроение!
покряхтел - писал однозначно ленивый дед!
Too much dependencies to install
А может мне ваш ТС и не нужОн!
Too much steps to do for quick setuping of linting
3 шага, на один проект. Мы же каждый день по 19 штук запускаем ? xD
Надо npx @feature-sliced/lint
сразу, ну))
Надо npx @feature-sliced/lint сразу, ну))
И сразу шоб конфиг патчил? 🤔
А как же: не нужОн мне ваш ТС? Есть же TS диссиденты в наших селеньях))
@Krakazybik Для "quickInstall" предлагаю к этому присмотреться 🤔
TLDR: Быстрый сетапинг через peerDeps
https://github.com/airbnb/javascript/tree/master/packages/eslint-config-airbnb#eslint-config-airbnb-1
https://github.com/airbnb/javascript/blob/master/packages/eslint-config-airbnb/package.json#L89
UPD: Еще вот такое есть 🤔
https://github.com/antfu/eslint-config/blob/master/packages/basic/package.json#L18
Т.е. я бы все же предложил пройтись по существующим конфигам и глянуть по ридмихе - как у них происходит сетапинг
(возможно "ручная установка плагинов" уже рили прошлый век)
А для "alwaysTryTypes" - я бы проверил, насколько он нужен для нашего boundaries/elements-types
🤔
Т.к. помню при тестировании на других проектах - иногда работало и без alwaysTryTypes
(а там где не работало, возможно я коряво typescript-parser поставил - предлагаю проверить еще раз, чтобы людям не приходилось обмазываться TS конфигами, которые в рамках нашего eslint-config не нужны)
@azinit Какие изыскания у меня вышли на данный момент:
alwaysTryTypes
- без него у меня функциональность не ломалась. Пока можно вырезать - будут проблемы - вернём.yarn
- не умеет в peerDep'seslint
- насильное втягивание нашей версии - может привести к поломке линтера в проекте.eslint-plugin-import
,eslint-plugin-boundaries
по идее можно затащить в обычные dep's, но надо тестить с npm, yarn, pnpm насколько корректно это всё подцепится в каждом случае, чтоб не получилось что где-то не будут подцепляться зависимости.
Теперь идея с npx
не кажется овер-инженерной. 🤔 Попробую по ресёрчить в этом направлении.
На первый взгляд npx
убивает всех зайцев, хоть их и безумно жалко =(
@illright Кста, если у тебя есть идеи как "улучшить сетапинг линтера", тоже можешь тут поделиться))
Особенно учитывая, что у тебя больше болело 😏
@Krakazybik спасибо что расписал!
Кажется что да, npx вполне компромиссный и не сильно затратный вариант остается 🤔
Ну я вот тут сейчас поразмыслил, погуглил про то, что такое плагин, что такое конфиг, понял, что беда. Не знаю даже, как и улучшить. Тут я бы, наверное, предложил ридми немного переписать, чтоб было меньше нагрузки на моск.
- Убрать пункт про необходимость установки ESLint
Во-первых, если люди не знают, что такое ESLint, им не сюда
Во-вторых, пакетные менеджеры умеют кричать на отсутствие пир-зависимостей, давайте отгрузим на них эту нелегкую ношу работать с пользователями, которые не успели еще поставить себе ESLint - Убрать команды для
yarn
Обычно это, конечно, хорошо — иметь их, но тут каждая команда сопровождается огромным списком целей установки, из-за чего блок команд визуально больше, чем он есть на самом деле. Думаю, мы не сильно нагрузим пользователейyarn
, если попросим их написатьyarn add -D
самим. (for recommended rules). You can omit the eslint-config postfix
Вот это всё тоже просто убрать) не знаю, зачем оно там
С тайпскриптом, конечно, какая-то срань. Понимаю, что от нас тут ничего не зависит. Решение тут вижу, но сначала расскажу о том, как я себя чувствовал, проходя через этот процесс установки:
Вот примерно мои мысли тогда
- Так, надо установить ESLint. У меня уже есть ESLint, зачем мне напоминать?
- Так, надо установить конфигу и зависимости. Блин, почему так много зависимостей(( что все это такое вообще, и зачем
- Так, надо добавить конфигу в
eslintrc
, тут стандартно, sample text пропускаем - Так, TypeScript-only. У меня тайпскрипт на проекте, надо сделать, открываем спойлер
- Боже, еще такая же пачка зависимостей(( и ведь по-любому какая-то из них у меня уже есть, сейчас надо еще разбираться в этом, чтоб не накатить чего лишнего
Решение: отгрузить процесс настройки TS для ESLint на другой туториал, добавив на него ссылку. @typescript-eslint/eslint-plugin @typescript-eslint/parser
уже установлены у тех людей, у которых работает ESLint с TS. Тогда TS-специфичная установка становится намного проще:
- накатить
eslint-import-resolver-typescript
- добавить мини-блок в
settings
вeslintrc
@illright Много с чем согласен, но вот "сделать неявным описание зависимостей, и уж тем более вынести в другой туториал" - кмк уже чересчур
Причем тут не уровень разработчика будет влиять, а в целом отношение "к неявностям"
Т.е. человек установит конфиг, думая что все ОК
А там нате - и он не запускается из-за плагинов
И тогда уже вместо твоих описанных мыслей будет что-то типа Блен, а сложно было в описание добавить плагины?!
(а у некоторых отторжение может быть еще на этапе прочтения README, т.к. по нему непонятно, что за начинка)
Я бы на самом деле тоже постарался оставить варик с peerDeps, но увы для того же ярна он фигово работает
(да и немного неявности есть)
Пока все склоняется к тому, чтобы npx скрипт запилить, наподобие eslint-kit