Анализ и исправление React с помощью Vim, ALE, XO и Prettier

тл;др
Поднимите настройку vim здесьи package.json здесь

Свернутый.
Ах… да… то, что вам нужно добавить в проект, что вы просто не хотите добавлять. Но этот тихий голос в твоей голове говорит тебе сделать это, потому что… Просто потому что.
Это как тестирование. Я всегда откладывал добавление тестов или линтинга, потому что они казались бесполезной работой.

Все изменилось, когда некоторое время назад я программировал на Python. Существуют плагины, такие как black и iSort, которые выполняют множество полезных процедур очистки кода. Например, изосортировать разумно сортирует импорт. Черный форматирует код для меня, чтобы я больше не беспокоился о том, что эта строка Python имеет неправильный отступ.
Это напоминает мне эту цитату:

«Пробудите в другом страстное желание». — Дейл Карнеги

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

Вернемся к Реакции. у меня уже есть Но установлен в vim, и он творил чудеса с обоими black а также isort. Тем не менее, он сделал ужасную работу с javascript. Он всегда думал, что все мои файлы были сломаны.
Это было потому, что красивее хотел отформатировать вещи таким образом, чтобы Хо не понял. Я установил оба, но не успел заставить их разговаривать друг с другом! Это заставило меня перезагрузить мой vimrc каждый раз, когда я открывал новый файл, чтобы отключить линтинг. Ужасный UX!
Итак, сегодня я решил потратить время, чтобы решить эту проблему раз и навсегда.

правила package.json

package.json правила, правила!
Раньше нам нужно было добавить .eslintrc а также .babelrc а также webpack.config.js .nodemonignore в корне каждого проекта. Вроде… по-настоящему. Это была одна из причин, по которой я игнорировал линтинг: мне казалось, что поддерживать его очень сложно. Или я просто искал ленивые оправдания?
Но я знаю, что некоторые из вас используют это оправдание. Давай не прячься

Давайте двигаться дальше.

По всей видимости, package.json может содержать правила, которые в противном случае находились бы в этих файлах. Вы только посмотрите на эту красоту:

// package.json
{
  "name": "package-name"
  "devDependencies":{
     ...
  }
  "nodemonConfig": {
     ...
  },
  "babel": {
     ...
  },
  "xo": {
    "prettier": true,
     ...
  },
  "husky": {
     ...
  }
}

Фантастика!

вим конфиг

У нас есть конфигурация в package.jsonно как мы делаем vim понимать это? Другими словами, как будет Но читать этот конфиг?

Перво-наперво. Ale предоставляет интерфейс для обоих linters и fixers.

let b:ale_fixers = {'python': ['black', 'isort'], 'javascript': ['xo']}
let b:ale_linters = {'python': ['pyflakes'], 'javascript': ['xo']}

Здесь я говорю Але исправить js с помощью xo и питон с black а также isort. Затем я говорю ему lint python с pyflakesи javascript с xo.
Но если я переключил js fixer на Prettierвещи больше не работали должным образом, потому что xo не совсем нравится то, что делает Красотка. я мог бы добавить xo настройки внутри .vimrc:

let g:ale_javascript_xo_options = "--plug=react --prettier"

Но это плохая идея, потому что не все используют vim!
Теперь, оказывается, xo можно сказать использовать Prettier в качестве фиксатора, И это можно сделать внутри package.json:

{
  "xo": {
    "prettier": true,
  }
}

Но этого недостаточно. xo использует eslint под капотом, а eslint по умолчанию не понимает реакции. Он выдаст ошибки в правильных операторах jsx:

import Header from './Header' 

По этой причине нам необходимо обновить xo конфигурации и добавьте несколько зависимостей разработчика.

"devDependencies": {
+    "eslint-config-xo": "^0.26.0",
+    "eslint-config-xo-react": "^0.19.0",
},
"xo": {
  "prettier": true,
+   "extends": "xo-react",
}

Сделав это, vim, наконец, исправит js с помощью Prettierи очистите его с помощью xo.
Но правил недостаточно.

Но правила по умолчанию не всегда соответствовали моему вкусу. Например, я не был согласен с тем, как мне хотелось использовать кебаб-кейс для имен моих файлов. К счастью, это было легко отключить:

"xo": {
  "prettier": true,
  "extends": "xo-react",
+   "rules": {
+     "unicorn/filename-case": 0,
+   }
}

И да, это точный синтаксис, используемый для eslint, и это не требует специального раздела eslint или .eslintrc. Сладкий!

Принудительный линтинг

Итак, у меня есть линтинг на месте, но у меня было предчувствие, что, если я не заставлю это произойти, я могу провиснуть. Итак, я вспомнил, что некоторые люди применяли линтинг как предварительный хук git.
Я огляделся и наткнулся хаски который делает именно это, и угадайте, что? Его можно настроить внутри package.json!🙈

Вот как все выглядит:

// package.json
{
  "scripts":{
+    "test": "xo --fix"
  },
+ "husky": {
+   "hooks": {
+     "pre-commit": "npm test"
+   }
+ }
}

Таким образом, перед каждым коммитом npm test запущен, и на данный момент этот скрипт будет запускать xo.
Я не возражаю против принудительного линтинга перед каждым коммитом (это означает, что фиксация не будет разрешена, если линтинг не сработает). Однако это можно сделать только перед фиксацией. В этом случае замените скрипт на:

// package.json
{
  "husky": {
    "hooks": {
-   "pre-commit": "npm test"
+   "pre-push": "npm test"
    }
  }
}

И вуаля! Теперь, независимо от того, какая у вас IDE, пока Prettier а также xo установлены глобально, каждый разработчик в команде будет вынужден проверять.
тинг здесь …