feature-sliced / eslint-config

🍰 Lint feature-sliced concepts by existing eslint plugins

Home Page:https://npmjs.com/@feature-sliced/eslint-config

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

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

#75 (comment)

About alwaysTryTypes

image

About bootstrapping

image

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

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

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's
  • eslint - насильное втягивание нашей версии - может привести к поломке линтера в проекте.
  • eslint-plugin-import, eslint-plugin-boundaries по идее можно затащить в обычные dep's, но надо тестить с npm, yarn, pnpm насколько корректно это всё подцепится в каждом случае, чтоб не получилось что где-то не будут подцепляться зависимости.

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

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

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

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

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

  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

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

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

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


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

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