# Eslint

poster
Сегодня мы с вами поговорим о том, как обнаруживать и предотвращать простейшие ошибки в javascript с помощью линтера Eslint.
Понравилось? Поделитесь с друзьями!
Понравилось?
Поделитесь с друзьями!
Комментарии
Текст видео

Сегодня мы с вами поговорим о том, как обнаруживать и предотвращать простейшие ошибки в javascript. Как известно, javascript не компилируемый язык, а это значит, что у нас нет этапа, который позволит нам отловить ошибки до того, как приложение запустится. И это очень сильно усложняет жизнь.

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

Самый популярный инструмент на сегодняшний день для этого - это eslint. Вы просто вызываете eslint с командной строки либо встраиваете его в watch таску, например в вебпак. И каждый раз, когда вы изменяете файл, eslint перезапускается и выводит вам ошибки.

Давайте его установим

npm install eslint --save-dev

Мы устанавливаем пакет только для девелопмента, так как в продакшене он не нужен.

Теперь давайте добавим команду lint и в ней вызовем eslint на файл main.js

"lint": "eslint main.js"

Теперь давайте выполним в консоли

npm run lint

Как мы видим, у нас вывалилась ошибка, что у нас нет конфигурационного файла eslint и чтобы это пофиксить нужно написать

eslint --init

Но так как мы установили eslint локально, как обычно делают в нормальных проектах, то эта команда нам скажет что eslint не найден. Давайте выполним команду используя локальный eslint

./node_modules/.bin/eslint --init

У нас открылся список вопросов.

  1. Выбираем Inspect javascript files
  2. Указываем main.js
  3. Формат конфиг файла javascript
  4. Es6 фичи нам не нужны
  5. Будем ранить код только в браузере
  6. Common JS не используем
  7. И JSX тоже

Мы видим сообщение, что у нас создался .eslintrc.js и в него добавилось 244 правила. Если мы откроем этот файл, то увидим, что у нас там создалось огромное количество правил.

Если мы запустим npm run lint еще раз, то ошибок у нас не найдет, так как у нас пустой файл.

Давайте попробуем написать обычный console.log

console.log('main.js')

Как вы видите, мне в Atome уже подсветились ошибки eslint, так как у меня установлен для него плагин. Вы можете установить расширение eslint практически для любого редактора.

Давайте вызовем eslint еще раз в консоли. И мы получили кучу ошибок

1:1   error  Unexpected console statement        no-console
1:13  error  Strings must use doublequote        quotes
1:23  error  Missing semicolon                   semi
2:1   error  Newline not allowed at end of file  eol-last

Оно нам говорит, что у нас в коде не должно быть console.log вообще. Строки должны быть в двойных кавычках. Пропущена точка с запятой и в файле не должно быть висячих строк.

Обычно, когда люди видят такое количество ошибок, то сразу реакция "О черт, зачем мне это надо. Это ж все ошибки нужно постоянно фиксить и вообще console.log не ошибка".

Для этого есть несколько вариантов:

  1. Вы можете переопределить все правила в файле eslintrc, которые вам не нравятся
  2. Вы можете использовать какой-то из популярных кодстайлов
  3. Вы можете и использовать чей то кодстайл и перекрыть их правила, которые вам не нравятся

Если мы посмотрим в eslintrc, то там есть секция extends, где у нас указано eslint:recommended. То есть у нас могло бы вообще не быть правил в файле, а мы просто указали бы extends и получили бы чей то конфиг.

Давйте попробуем перекрыть правила, которые нам не нравятся. Вот, например, у нас была ошибка "Strings must use doublequote". То есть строки должны быть в двойных кавычках. А я всегда пишу в одинарных. Как вы видите, справа от ошибки написан ее алиас и мы можем ее найти в нашем конфиге

Как вы видите, у нас указан

"quotes": "error"

Как же нам узнать что писать, чтобы у нас eslint валидировал одинарные кавычки, а не двойные? Для этого заходим на сайт eslint.org в раздел rules и прямо в url можем найти по алиасу правило

http://eslint.org/docs/rules/quotes

И там на каждое правило есть отличная документация с примерами. И в данном случае мы видим, что мы можем написать

"quotes": ["error", "single"]

Если мы откроем консоль, то увидим, что ошибка про кавычки у нас исчезла, но если мы попробуем поставить сейчас двойные кавычки, то она опять появится.

Таким образом вы можете менять каждое правило на свой вкус

В eslint по умолчанию нет watch мода и обычно он вставляется в момент транспайла js. Но если вы хотите просто запустить eslint в watch моде, то можете установить плагин eslint-watch

npm i eslint-watch --save-dev

Теперь можем добавить еще один скрипт в package.json

"lint:watch": "esw main.js -w"

это запустит eslint в watch моде и теперь все ошибки в консоли будут показываться на лету

Если у вас возникли какие-то вопросы или комментарии, пишите их прямо под этим видео.

Только зарегистрированные пользователи могут оставлять комментарии.  Войдите, пожалуйста.
ilya kuz
8 лет назад
Спасибо за урок! А если я создаю приложение React и все рендерится в итоге в один компонент <App/>, который может быть завернут в Provider, Router и т.д., какой файл нужно указать линтеру как точку входа?
monsterlessons
8 лет назад
На здоровье. Линтеру не нужно указывать точку входа. Он просто парсит указанные по расширению файлы в директории.
Игорь Белогуров
9 лет назад
А что если не запускать линт через npm, а встроить проверку сразу в редактор кода? Есть примеры?
monsterlessons
9 лет назад
Почти все редакторы кода сейчас поддерживают линт внутри. Например в Webstorm достаточно в настройках поставить галочку eslint и указать путь к npm пакету eslint. Atom, Sublime, Visual studio code поддерживают линтер тоже с помощью дополнительных плагинов. Основная же идея линта не в редакторе - это проверка кода при коммите, чтобы в репозиторий не попадал код без кодстайла.
Игорь Белогуров
9 лет назад
Сам пользуюсь штормом, но немного устал от его "тяжеловестности", и хочется собрать нечто полегче на базе атома. Поставил несколько линтов через внутренний менеджер пакетов, хотелось бы смотреть на правки сразу во время редактирования. --fix уже после - хорошо, но именно хотелось в процессе
monsterlessons
9 лет назад
Я тоже пользуюсь IDEA и оно очень лагает на 8гб оперативы. Пробовал атом, вим, visual code, но у всех одна проблема - даже если их долго настраивать не получится так удобно как в IDEA. Там убогие мердж тулы, go to definition, инспект измененных файлов и удобный rollback, локальная история, отличный поиск и тп. По поводу линтера я предпочитаю фиксить весь линт при коммите, так как постоянные подсказки как писать отвлекают от фокуса на коде имхо. Если что гит хуки при коммите очень удобно вешать с помощью husky. https://github.com/typicode/husky
Дмитрий Мищенко
9 лет назад
Спасибо, за урок, подскажите а Вы не планируете снимать еще уроки по реакту? Вы говорили что Вы его используете больше всего, и было бы очень познавательно. Может быть что-то вроде серии уроков по Trello?
monsterlessons
9 лет назад
Будет обязательно, но скорее всего уже платно, по месячной подписке.