LINT: (Feedback) Refine bootstraping of linting

[azinit]

Problem

• Redundant TS settings alwaysTryTypes?
• Too much dependencies to install
• Too much steps to do for quick setuping of linting

Reference

#75 (comment)

[azinit]

About alwaysTryTypes

[azinit]

About bootstrapping

[Krakazybik]

Сегодня весёлое настроение!

покряхтел - писал однозначно ленивый дед!

Too much dependencies to install

А может мне ваш ТС и не нужОн!

Too much steps to do for quick setuping of linting

3 шага, на один проект. Мы же каждый день по 19 штук запускаем ? xD

[azinit]

Надо npx @feature-sliced/lint сразу, ну))

[Krakazybik]

Надо npx @feature-sliced/lint сразу, ну))

И сразу шоб конфиг патчил? 🤔

А как же: не нужОн мне ваш ТС? Есть же TS диссиденты в наших селеньях))

[azinit]

@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

---

Т.е. я бы все же предложил пройтись по существующим конфигам и глянуть по ридмихе - как у них происходит сетапинг
(возможно "ручная установка плагинов" уже рили прошлый век)

[azinit]

А для "alwaysTryTypes" - я бы проверил, насколько он нужен для нашего boundaries/elements-types 🤔

Т.к. помню при тестировании на других проектах - иногда работало и без alwaysTryTypes
(а там где не работало, возможно я коряво typescript-parser поставил - предлагаю проверить еще раз, чтобы людям не приходилось обмазываться TS конфигами, которые в рамках нашего eslint-config не нужны)

[Krakazybik]

@azinit Какие изыскания у меня вышли на данный момент:

• alwaysTryTypes - без него у меня функциональность не ломалась. Пока можно вырезать - будут проблемы - вернём.
• yarn - не умеет в peerDep's
• eslint - насильное втягивание нашей версии - может привести к поломке линтера в проекте.
• eslint-plugin-import, eslint-plugin-boundaries по идее можно затащить в обычные dep's, но надо тестить с npm, yarn, pnpm насколько корректно это всё подцепится в каждом случае, чтоб не получилось что где-то не будут подцепляться зависимости.

Теперь идея с npx не кажется овер-инженерной. 🤔 Попробую по ресёрчить в этом направлении.
На первый взгляд npx убивает всех зайцев, хоть их и безумно жалко =(

[azinit]

@illright Кста, если у тебя есть идеи как "улучшить сетапинг линтера", тоже можешь тут поделиться))

Особенно учитывая, что у тебя больше болело 😏

[azinit]

@Krakazybik спасибо что расписал!
Кажется что да, npx вполне компромиссный и не сильно затратный вариант остается 🤔

[illright]

Ну я вот тут сейчас поразмыслил, погуглил про то, что такое плагин, что такое конфиг, понял, что беда. Не знаю даже, как и улучшить. Тут я бы, наверное, предложил ридми немного переписать, чтоб было меньше нагрузки на моск.

1. Убрать пункт про необходимость установки ESLint
   Во-первых, если люди не знают, что такое ESLint, им не сюда
   Во-вторых, пакетные менеджеры умеют кричать на отсутствие пир-зависимостей, давайте отгрузим на них эту нелегкую ношу работать с пользователями, которые не успели еще поставить себе ESLint
2. Убрать команды для yarn
   Обычно это, конечно, хорошо — иметь их, но тут каждая команда сопровождается огромным списком целей установки, из-за чего блок команд визуально больше, чем он есть на самом деле. Думаю, мы не сильно нагрузим пользователей yarn, если попросим их написать yarn add -D самим.
3. (for recommended rules). You can omit the eslint-config postfix
   Вот это всё тоже просто убрать) не знаю, зачем оно там

С тайпскриптом, конечно, какая-то срань. Понимаю, что от нас тут ничего не зависит. Решение тут вижу, но сначала расскажу о том, как я себя чувствовал, проходя через этот процесс установки:

Вот примерно мои мысли тогда

1. Так, надо установить ESLint. У меня уже есть ESLint, зачем мне напоминать?
2. Так, надо установить конфигу и зависимости. Блин, почему так много зависимостей(( что все это такое вообще, и зачем
3. Так, надо добавить конфигу в eslintrc, тут стандартно, sample text пропускаем
4. Так, TypeScript-only. У меня тайпскрипт на проекте, надо сделать, открываем спойлер
5. Боже, еще такая же пачка зависимостей(( и ведь по-любому какая-то из них у меня уже есть, сейчас надо еще разбираться в этом, чтоб не накатить чего лишнего

Решение: отгрузить процесс настройки TS для ESLint на другой туториал, добавив на него ссылку. @typescript-eslint/eslint-plugin @typescript-eslint/parser уже установлены у тех людей, у которых работает ESLint с TS. Тогда TS-специфичная установка становится намного проще:

• накатить eslint-import-resolver-typescript
• добавить мини-блок в settings в eslintrc

[azinit]

@illright Много с чем согласен, но вот "сделать неявным описание зависимостей, и уж тем более вынести в другой туториал" - кмк уже чересчур

Причем тут не уровень разработчика будет влиять, а в целом отношение "к неявностям"
Т.е. человек установит конфиг, думая что все ОК
А там нате - и он не запускается из-за плагинов

И тогда уже вместо твоих описанных мыслей будет что-то типа Блен, а сложно было в описание добавить плагины?!
(а у некоторых отторжение может быть еще на этапе прочтения README, т.к. по нему непонятно, что за начинка)

---

Я бы на самом деле тоже постарался оставить варик с peerDeps, но увы для того же ярна он фигово работает
(да и немного неявности есть)

Пока все склоняется к тому, чтобы npx скрипт запилить, наподобие eslint-kit