Eslint: как быстро найти и предотвратить ошибки

Настройка ESLint

У ESLint есть конфиг, в котором находятся правила, согласно которым он выполняет проверку кода. Как я говорил ранее, ESLint уже встроен в Create React App, и использует конфиг который называется eslint-config-react-app

В Create React App этот конфиг подключается к ESLint в package.json, 22 строка:

Eslint сейчас настроен так, как решили создатели CRA. Давайте инициализируем ESLint и заново сами все настроим, так, как нам необходимо. Для этого выполним команду:

Enter fullscreen modeExit fullscreen mode

Запустится мастер настройки ESLint.
Пройдем настройку согласно предложенным вариантам:

В конце мастер создаст файл настроек линтера, .eslintrc.json:

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

Эксперимент первый

Создадим два файла с одинаковым с виду содержимым:

first line
second line
third line

Первый файл с именем crlf.txt будет содержать этот текст с переводами строк \r\n:

А второй, с именем lf.txt будет содержать переводы строк \n:

Теперь создадим репозиторий, который будет считаться основным, для этого в папке с только что созданными файлами выполним команду:

git init

После этого добавим файлы к коммиту:

git add .

При этой операции мы получим следующее предупреждение:

warning: LF will be replaced by CRLF in lf.txt

Git предупреждает о том, что переводы строк в файле lf.txt будут заменены на \r\n. Нам отступать некуда, поэтому все-таки выполняем коммит:

git commit -m «commit comment»

Git еще раз выведет то же самое предупреждение, но коммит сделает:

 commit comment
warning: LF will be replaced by CRLF in lf.txt
 2 files changed, 6 insertions(+), 0 deletions(-)
 create mode 100644 crlf.txt
 create mode 100644 lf.txt

Если теперь мы посмотрим на наши исходные файлы, то они не изменились, что логично. А теперь сделаем клон этого репозитория.

git clone <путь до исходного репозитория>

Если теперь посмотрим на файлы клона в 16-ричном редакторе, то увидим, что оба файла crlf.txt и lf.txt имеют переводы строк \r\n. Получилось, что файлы lf.txt в исходном репозитории и в клоне стали разные, хотя git их считает идентичными. Это произошло из-за того, что в самом начале мы установили значение core.autocrlf в true в конфиге пользователя, поэтому такое значение и будет применяться для только что созданного репозитория по умолчанию, то есть это значение установлено в true для обоих репозиториев.

Давайте теперь изменим файл lf.txt в клоне, добавив еще одну строку, причем переводы строк оставим как \r\n:

first line
second line
third line
fourth line

Сделаем коммит и отправим изменения обратно в главный репозиторий:

git commit -a -m "change lf.txt"
git push

Напомню, что параметр -a у команды git commit указывает, что к коммиту нужно добавить все измененные файлы, которые уже есть в репозитории (но не новые).

Теперь в главном репозитории выполняем следующую команду, чтобы исходники рабочей копии соответствовали содержимому репозитория:

git reset —hard

Смотрим что стало с содержимым файла lf.txt в шестнадцатеричном редакторе и видим:

В нем переводы строк тоже поменялись на \r\n, теперь в файле lf.txt в обоих репозиториях находятся файлы с одинаковыми переводами строк.

Форматы файлов конфигурации

ESLint поддерживает файлы конфигурации в нескольких форматах:

JavaScript — используйте и экспортируйте объект, содержащий вашу конфигурацию.

JavaScript (ESM) — используйте при запуске ESLint в пакетах JavaScript, которые указывают в своем

Обратите внимание, что ESLint в настоящее время не поддерживает конфигурацию ESM.

YAML — используйте или для определения структуры конфигурации.

JSON — используйте для определения структуры конфигурации. Файлы JSON ESLint также допускают комментарии в стиле JavaScript.

package.json — создайте свойство в файле и определите там свою конфигурацию.

Если в одном каталоге находится несколько конфигурационных файлов,ESLint будет использовать только один.Порядок приоритетов следующий:

Git замена LF на CRLF

Запуск git на компьютере под управлением Windows XP с помощью bash. Я экспортировал свой проект из SVN, а затем клонировал голый репозиторий.

Затем я вставлял экспорт в каталог с пустыми репозиториями и делал:

Затем я получил список сообщений:

LF будет заменен на CRLF

Каковы последствия этого преобразования? Это .NET-решение в Visual Studio.

Эти сообщения вызваны неправильным значением по умолчанию core.autocrlf в Windows.

Концепция autocrlf заключается в прозрачной обработке преобразования концов строк. И это делает!

Плохие новости: значение необходимо настроить вручную. Хорошие новости: это следует делать ОДНО раз за установку git (также возможна настройка каждого проекта).

Как работает autocrlf :

Здесь crlf = маркер конца строки в стиле win, lf = стиль unix (и mac osx).

(pre-osx cr не затронут ни одним из трех вариантов выше)

Когда появляется это предупреждение (под Windows)

— autocrlf = true , если у вас есть lf в стиле Unix в одном из ваших файлов (= В РЕЖИМЕ), — autocrlf = input , если у вас есть стиль crlf в одном из ваших файлов (= почти ВСЕГДА), — autocrlf = false — НИКОГДА!

Что означает это предупреждение

Предупреждение «LF будет заменено на CRLF» говорит о том, что вы (имея autocrlf = true ) потеряете свой LF в стиле Unix после цикла фиксации (он будет заменен CRLF в стиле Windows). Git не ожидает, что вы будете использовать LF в стиле Unix под Windows.

Предупреждение «CRLF будет заменен LF» говорит о том, что вы (имея autocrlf = input ) потеряете свой CRLF в стиле Windows после цикла фиксации (он будет заменен LF в стиле Unix). Не используйте input под окнами.

Еще один способ показать, как работает autocrlf

где x — это CRLF (в стиле Windows) или LF (в стиле Unix), а стрелки обозначают

Как исправить

Значение по умолчанию для core.autocrlf выбирается во время установки git и сохраняется в общесистемном gitconfig ( %ProgramFiles(x86)%gitetcgitconfig ). Также есть (каскадирование в следующем порядке):

— «глобальный» (для пользователя) gitconfig, расположенный в

/.gitconfig , еще один — «глобальный» (для пользователя) gitconfig в $XDG_CONFIG_HOME/git/config или $HOME/.config/git/config и — «local» (per-repo) gitconfig в .git/config в рабочем каталоге.

Итак, напишите git config core.autocrlf в рабочем каталоге, чтобы проверить текущее используемое значение, и

— добавить autocrlf=false в общесистемное решение gitconfig # для системы — git config —global core.autocrlf false # решение для каждого пользователя — git config —local core.autocrlf false # решение для каждого проекта

Предупреждения— Настройки git config могут быть переопределены настройками gitattributes .— Преобразование crlf -> lf происходит только при добавлении новых файлов, на файлы crlf , уже существующие в репо, это не влияет.

Мораль (для Windows): — используйте core.autocrlf = true , если вы планируете использовать этот проект также под Unix (и не хотите настраивать ваш редактор /IDE для использования концов строк Unix), — используйте core.autocrlf = false , если вы планируете использовать этот проект только под Windows (или вы настроили свой редактор /IDE для использования концов строк Unix), — никогда не используйте core.autocrlf = input , если у вас нет веских причин (например, если вы используете утилиты Unix под Windows или если у вас возникают проблемы с makefiles),

PS Что выбрать при установке git для Windows? Если вы не собираетесь использовать какой-либо из ваших проектов под Unix, не соглашайтесь с первым вариантом по умолчанию. Выберите третий (Оформить как есть, зафиксировать как есть). Вы не увидите это сообщение. Когда-либо.

4: Форматирование при сохранении

Чтобы ESLint мог автоматически исправлять синтаксис и устранять ошибки форматирования при каждом сохранении, вам нужно открыть меню настроек. Меню в Visual Studio Code – это значок шестеренки в левом нижнем углу. Нажмите его и выберите Settings.

В меню настроек найдите Code Actions on Save. Первой идет опция Editor: Code Actions on Save, а ниже – Edit in settings.json, и как раз она нам нужна.

Файл settings.json откроется в редакторе кода. Чтобы ESLint исправлял ошибки при сохранении файла, вам нужно добавить следующий код в settings.json:

С помощью этого кода ESLint сможет автоматически исправляет ошибки и проверяет JavaScript при сохранении.

Вернитесь к файлу app.js и сохраните его. Вы увидите, что линтер внес некоторые изменения, и цвет подчеркивания тоже изменился. Вот некоторые из ошибок форматирования, которые исправил ESLint:

Теперь одинарные кавычки использованы последовательно.
Точки с запятой – тоже.
Отступ внутри функции расставлены правильно.

ESLint автоматически будет устранять синтаксические ошибки при сохранении файла app.js. Но пока у нас еще остались сообщения об ошибках. Их можно исправить, настроив ESLint для обнаружения или игнорирования определенных ошибок и проблем с форматированием.

Эксперимент второй

До сих пор у нас для обоих репозиториев значения параметра core.autocrlf были установлены в true, давайте теперь создадим новый репозиторий, но в котором значение этого параметра будет установлено в false.

Возьмем все тот же исходный файл lf.txt с переводом строк \n:

first line
second line
third line

Создадим репозиторий в папке с этими файлами:

git init

Установим значение параметра core.autocrlf в false:

git config core.autocrlf false

Глобальное значение этого параметра по-прежнему остается true, но для данного репозитория это уже не играет роли.

Теперь добавим файл к коммиту:

git add .

На этот раз предупреждения не будет, так как в репозиторий файлы будут добавлены с теми переводами строк, что и были созданы. Выполняем коммит:

git commit -m «Commit comment»

В результате ничего экстраординарного не произойдет, коммит будет произведен удачно:

 Comment commit
 1 files changed, 3 insertions(+), 0 deletions(-)
 create mode 100644 lf.txt

А теперь создадим клон этого репозитория:

git clone <путь до главного репозитория>

Дело в том, что для этого нового репозитория-клона файл конфига не будет содержать параметра core.autocrlf, поэтому по умолчанию будет использоваться то значение, которое мы установили в самом начале, то есть true. А раз этот параметр установлен в true, то при создании файлов переводы строк будут преобразованы в \r\n, что мы и увидим в файле lf.txt:

5: Пользовательская настройка ESLint

«Из коробки» ESLint подчеркивает все операторы console.log() в app.js. В некоторых случаях распознавание операторов console.log в качестве ошибки может быть не в приоритете. Вы можете игнорировать операторы console.log.

Правила конфигурации ESLint можно изменить в файле .eslintrc.json.

Откройте файл .eslintrc.json. В этом файле вы увидите такой код:

В конце файла .eslintrc.json вы увидите объект «rules». Чтобы настроить триггеры ESLint (или отключить реакцию ESLint на определенные фрагменты кода), нужно добавить пары «ключ-значение» к объекту «rules». Ключ – это название правила, которое нужно добавить или изменить. Значение задает уровень серьезности проблемы. ESLint поддерживает три уровня серьезности:

error – подчеркивается красным
warn – подчеркивается желтое
off – ничего неподчеркивается.

Если вы не хотите подчеркивать операторы console.log как ошибки, вы можете назвать правило no-console и указать это имя в качестве ключа. Используйте off как значение:

Это правило удаляет подчеркивание операторов console.log в app.js.

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

Если теперь вы включите в код одинарные кавычки, ESLint выдаст ошибку.

2: Установка и настройка ESLint

Чтобы установить ESLint, введите:

В эту команду важно включить флаг –save-dev, поскольку он сохраняет пакет как зависимость разработки – и тогда он будет использован только в разработке, но не в производстве. Пакет eslint нужен только тогда, когда вы активно работаете над кодом и вносите изменения в свой проект

Как только ваш проект будет на стадии производства, eslint больше не понадобится. И флаг –save-dev гарантирует, что eslint будет указан в вашем файле package.json только как зависимость разработки.

Теперь, когда ESLint установлен, вы можете инициализировать конфигурацию ESLint для своего проекта, используя для этого следующую команду:

Важным элементом этой команды является флаг –init. Раздел ./node_modules/.bin/eslint этой команды – это путь к ESLint в вашем проекте. Флаг –init активирует ESLint для вашего проекта. Процедура активации или инициализации ESLint создаст конфигурационный файл, который позволит вам настроить ESLint для вашего проекта.

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

Первый вопрос будет выглядеть так:

Здесь мы выберем To check syntax, find problems, and enforce code style – чтобы программа проверяла синтаксис, сообщала о проблемах и поддерживала единый стиль кода.

Следующий вопрос выглядит так:

Выберите опцию CommonJS, чтобы использовать глобальные переменные CommonJS.

В следующем вопросе будет сказано:

Выберите вариант None of these.

Затем программа спросит:

Выберите вариант No.

Затем появится такой вопрос:

Выберите Browser.

Затем вы увидите такой вопрос:

Выберите ответ Use a popular style guide.

На вопрос:

Ответьте Airbnb: https://github.com/airbnb/javascript.

Затем будет такой вопрос:

Нужно выбрать JSON.

Вы получите такое сообщение:

Последний вопрос программы выглядит так:

Выберите вариант Yes, чтобы установить зависимости с помощью npm.

Вам также будет предложено установить дополнительные пакеты. Выберите yes.

После всех вопросов вы заметите, что в ваш каталог linting был добавлен файл .eslintrc.json. Теперь инструмент ESLint установлен. Код в app.js пока не изменился – и это связано с тем, что ESLint необходимо интегрировать с Visual Studio Code.

Prettier

Prettier. Что это такое и зачем вообще нужно?

Prettier — это инструмент для автоматического форматирования кода.

Prettier берет код, который вы ему дали, и преобразует этот код к единому стилю.

Вот простой пример:

Здесь у нас стандартный файл App.js из Create React App проекта, у которого я где то убрал, а где то добавил отступы и точки с запятыми в конце строк, в некоторых местах использовал длинные, плохо читаемые строки.

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

Removed

deprecation policy

Removed rule	Replaced by
generator-star	generator-star-spacing
global-strict	strict
no-arrow-condition	no-confusing-arrow no-constant-condition
no-comma-dangle	comma-dangle
no-empty-class	no-empty-character-class
no-empty-label	no-labels
no-extra-strict	strict
no-reserved-keys	quote-props
no-space-before-semi	semi-spacing
no-wrap-func	no-extra-parens
space-after-function-name	space-before-function-paren
space-after-keywords	keyword-spacing
space-before-function-parentheses	space-before-function-paren
space-before-keywords	keyword-spacing
space-in-brackets	object-curly-spacing array-bracket-spacing
space-return-throw-case	keyword-spacing
space-unary-word-ops	space-unary-ops
spaced-line-comment	spaced-comment

Интеграция Prettier в VS Code

Установим расширение Prettier для VS Code:

После того как мы установили расширение Prettier в VS Code, можно сделать так, чтобы Prettier автоматически форматировал наш код, когда мы сохраняем файл. Для этого нужно добавить два значения в JSON конфиг VS Code, (файл settings.json).

Чтобы открыть settings.json нужно, находясь в VS Code, нажать Ctrl + Shift + P, ввести в поиск «settings» и выбрать пункт Open Settings (JSON). Откроется файл settings.json.

Добавим в него следующие строки:

Enter fullscreen modeExit fullscreen mode

Первая строка устанавливает Prettier как инструмент форматирования кода по-умолчанию.
Вторая строка включает форматирование кода при сохранении файла.

Персональные файлы конфигурации (устаревшие)

️ Эта функция устарела . Эта функция будет удалена в версии 8.0.0. Если вы хотите и дальше использовать личные файлы конфигурации, используйте параметр . Дополнительные сведения об этом решении см. В RFC 28 и RFC 32 .

относится к . Здесь упоминается файл личной конфигурации , Который в настоящее время обрабатывается иначе, чем другие файлы конфигурации.

Как ESLint находит личные файлы конфигурации?

Если не может найти какой-либо файл конфигурации в проекте, загружает файл .

Если может найти файлы конфигурации в проекте, игнорирует файл , Даже если он находится в родительском каталоге каталога проекта.

Как ведут себя личные конфигурационные файлы?

ведут себя аналогично обычным файлам конфигурации, за некоторыми исключениями:

загружают общие конфигурации и пользовательские парсеры из — аналогично — в домашний каталог пользователя

Обратите внимание, что он не загружает глобально установленные пакеты

по умолчанию загружают плагины из , чтобы однозначно идентифицировать плагины. Если вы хотите использовать плагины с , Плагины должны быть установлены локально для каждого проекта. В качестве альтернативы вы можете использовать параметр чтобы изменить место, из которого ESLint загружает плагины.

OpenJS Foundation и другие участникиЛицензия MIT.https://eslint.org/docs/user-guide/configuring/configuration-files

Ruby. Исповедь самоучки

Строки. Методы работы со строками. Часть II

Первая часть темы работы со строками находится здесь.2.20 String#chop, String#chop!

Методы обрезают последний символ строки кроме случая когда последними двумя символами является rn(виндовый переход на новую строку), тогда обрезаются оба символа.BANG метод #chomp! преобразует объект или возвращает nil , а #chomp возвращает новую строку.

Метод #chr возвращает первый символ (символьный тип character) строки.

Возвращает массив порядковых чисел множества символов character. Является сокращенной записью выражения str.each_codepoints.to_a . Если методу #codepoints передан блок кода, то ведет себя также как и each_codepoints

Каждый параметр other_str преобразуется в множество символов character. Метод подсчитывает количество символов str, которые принадлежат этому множеству. При помощи символа «галочка» (^) задаются исключения из множества. Выражения типа c1-c2 задают множество символов, которые располагаются между символами c1 и c2.

Применяет однопроходное криптографическое хеширование к строке str посредством функции crypt из стандартной библиотеки языка Си. Аргументом метода является строка salt_str, которая содержит «соль» для хеширования. Соль должна соответствовать регулярному выражению A.Пользоваться этим методом не рекомендовано из-за его простоты.

Метод возвращает копию строки str в которой удалены все символы переданные в other_str. Поиск символов для удаления происходит также как их подсчитывает метод #count (п. 2.23)

Все 4 метода управляют регистром символов

#downcase и #downcase! — нижний регистр, #upcase и #upcase! — верхний регистр.Важно. Действие методов распространяется только на латинские символы

Создает версию строки str в которой все непечатные символы заменены на nnn нотацию и все специальные символы (escape последовательности) экранированы.

Метод в цикле пробегает по каждому байту строки в заданном блоке кода. В случае если блок кода не задан, возвращается экземпляр класса Enumerator

В случае если методу передан блок кода, то в блок передается каждый символ строки. Если же блок не задан — возвращает экземпляр класса Enumerator

В случае если методу передан блок кода, то в блок передается порядковое число (цифровая ссылка) каждого символа строки. Если же блок не задан — возвращает экземпляр класса Enumerator

Метод #each_line разбивает строку str используя значение параметра separator, и передает каждую из подстроку в блок. Если в качестве параметра separator передается пустая строка, то строка будет делится по символу n (разрыв строки), исключая случай, когда несколько символов n идут подряд (все символы n будут засчитываться как один).

Метод возвращает true если длина строки равна нулю, иначе — false

Предупреждения точек останова

При отладке точка останова может иметь два визуальных состояния: закрашенный красный кружок или незакрашенный кружок (белая заливка). Если отладчик может успешно установить точку останова в целевом процессе, она будет отображаться как закрашенный красный кружок. Если точка останова отображается как незакрашенный кружок, либо точка останова отключена, либо при попытке установить ее возникло предупреждение. Чтобы определить причину, наведите указатель мыши на точку останова и проверьте, есть ли предупреждение.

В следующих двух разделах описаны наиболее часто возникающие предупреждения и способы их устранения.

«Нет загруженных символов для этого документа»

Перейдите в окно Модули (Отладка > Окна > Модули) и проверьте, загружен ли модуль.

Если модуль загружен, проверьте, загружены ли символы, в столбце Состояние символов.
- Если символы не загружены, проверьте состояние символов для диагностики проблемы. В контекстном меню модуля в окне Модули щелкните Сведения о загрузке символов… , чтобы узнать, откуда отладчик пытался загрузить символы. Дополнительные сведения о загрузке символов см. в статье Указание файлов символов (.pdb) и исходных файлов.
- Если символы загружены, PDB-файл не содержит сведений об исходных файлах. Возможно несколько причин.
  - Если исходные файлы были добавлены недавно, убедитесь в том, что загружается последняя версия модуля.
  - Можно создать очищенные PDB-файлы с помощью параметра компоновщика /PDBSTRIPPED. Очищенные PDB-файлы не содержат сведений об исходных файлах. Убедитесь в том, что вы работаете с полным, а не очищенным PDB-файлом.
  - PDB-файл частично поврежден. Удалите файл и выполните чистую сборку модуля, чтобы попытаться устранить проблему.
Если модуль не загружен, проверьте следующее, чтобы найти причину:
- Убедитесь в том, что выполняется отладка правильного процесса.
- Проверьте, выполняется ли отладка соответствующего кода. Узнать, для отладки какого типа кода настроен отладчик, можно в окне Процессы (Отладка > Окна > Процессы). Например, если вы пытаетесь выполнить отладку кода на C#, убедитесь в том, что ваш отладчик настроен для соответствующего типа и версии .NET (например, «Управляемый код (версия 4*)» «Управляемый код (версия 2* или версия 3*)» или «Управляемый код (CoreCLR)»).

«… текущий исходный код отличается от версии, построенной в…»

Если исходный файл изменился и исходный код больше не соответствует отлаживаемому коду, отладчик по умолчанию не будет устанавливать точки останова в коде. Как правило, эта проблема возникает, если исходный файл изменился, но исходный код не был перестроен. Чтобы устранить эту проблему, перестройте проект. Если система сборки считает, что проект уже обновлен, несмотря на то, что это не так, можно заставить ее перестроить проект, сохранив исходный файл еще раз или очистив выходные данные сборки проекта перед сборкой.

В редких случаях может потребоваться отладка без соответствующего исходного кода. Отладка без соответствующего исходного кода может привести к путанице при отладке, поэтому вы должны быть уверены, что именно это нужно сделать.

Чтобы отключить проверки безопасности, выполните одно из указанных ниже действий.

Чтобы изменить отдельную точку останова, наведите указатель мыши на значок точки останова в редакторе и щелкните значок параметров (в виде шестеренки). В редактор добавится окно просмотра. В верхней части окна просмотра есть гиперссылка, указывающая на расположение точки останова. Щелкните гиперссылку, чтобы разрешить изменение расположения точки останова, и установите флажок Разрешить наличие отличий в исходном коде от первоначальной версии.
Чтобы изменить этот параметр для всех точек останова, выберите Отладка > Параметры и настройки. На странице Отладка / Общие снимите флажок Требовать точного соответствия исходной версии файлов . Не забудьте снова включить этот параметр после завершения отладки.