prettier не форматирует код

Форматирование кода с помощью Prettier в Visual Studio Code

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

Данный мануал научит вас использовать инструмент Prettier, который автоматически форматирует код в Visual Studio Code (или VS Code)

Для демонстрации мы возьмем такой фрагмент кода:

Если вы знакомы с правилами форматирования кода, вы заметите несколько ошибок:

Требования

1: Команда Format Document

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

Чтобы открыть панель команд, нажмите Command+Shift+P в macOS или Ctrl+Shift+P в Windows.

В палитре команд найдите format, а затем выберите Format Document.

Затем панель может предложить вам выбрать формат, который нужно использовать. Для этого нажмите кнопку Configure.

Затем выберите Prettier – Code Formatter.

Примечание. Если панель не предложила вам выбрать формат по умолчанию, вы можете выбрать его вручную в Settings. Установите в Editor: Default Formatter значение ebsenp.prettier-vscode.

Теперь код будет отформатирован с учетом всех пробелов, переносов строк и правильных кавычек:

Это также работает для файлов CSS. Вы можете превратить код с неправильно расставленными скобками, точками с запятой и разбивкой на строки в хорошо отформатированный файл. Например, такой код:

Будет переформатирован так:

body <
color: red;
>
h1 <
color: purple;
font-size: 24px;
>

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

2: Форматирование кода при сохранении

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

Чтобы изменить этот параметр, нажмите Command+ в MacOS или Ctrl+ в Windows. Вы попадете в меню Settings. Открыв это меню, найдите параметр Editor: Format On Save и выберите его, поставив галочку.

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

3: Конфигурация Prettier

Prettier делает много полезного по умолчанию, но стандартное поведение можно изменить, отредактировав настройки.

Откройте меню Settings и найдите Prettier. На вашем экране появятся все параметры Prettier, которые вы можете изменить.

Вот несколько параметров, которые меняют чаще всего:

Главный недостаток встроенного меню конфигураций в VS Code – это то, что оно не обеспечивает согласованности настроек в вашей команде.

4: Создание конфигурационного файла Prettier

Даже если вы измените настройки Prettier в своем экземпляре VS Code, остальные разработчики в вашей команде могут использовать совершенно другую конфигурацию. Чтобы исправить эту ситуацию, можно установить для своего проекта последовательное форматирование с помощью конфигурационного файла.

Вот пример конфигурационного файла в формате JSON:

<
«trailingComma»: «es5»,
«tabWidth»: 4,
«semi»: false,
«singleQuote»: true
>

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

Заключение

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

Prettier обеспечивает согласованность кода и может форматировать его автоматически.

Источник

Руководство Eslint + Prettier

Руководство для настройки автоматического форматирования кода и проверки синтаксиса языка JavaScript. Рассказываем про утилиты Eslint и Prettier.

Введение

В этой статье мы рассмотрим основные правила линтера и способы его настройки под проект.

Какой цели я хочу достигнуть в результате?

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

Какие проблемы решает eslint?

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

Для чего тогда нам нужен Prettier?

Никогда не останавливайтесь:

В программировании говорят, что нужно постоянно учиться даже для того, чтобы просто находиться на месте. Развивайтесь с нами — на Хекслете есть сотни курсов по разработке на разных языках и технологиях.

Перейдем к настройке

Начну с того, что здесь описана настройка линтера на примере VScode. Для других IDE будет разница только в поиске нужных расширений. Итак:

Можете поэкспериментировать с настройками, чтобы понять, какой пункт меню за что отвечает. Итогом настройки будет являться сформированный файл .eslintrc.json. Вы можете создать файл с настройками самостоятельно и поместить его на один уровень с package.json.

Для того, чтобы наша проверка работала, нам нужно установить необходимые пакеты:

Пример настройки файлов для работы ESLint:

[0]=off // выключает правило

[1]=warn // выводит предупреждение в консоль

[2]=error // выводит error и останавливает исполнение программы

*Правила оформления кода. Полный список настроек вы можете найти здесь.

Чтобы исключить из проверки директории/файлы указываем их в виде списка

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

Для автоматического форматирования нам нужно

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

TROUBLESHOOTING

Заключение

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

Прокачивайте свой уровень программирования:

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

С нуля до разработчика. Возвращаем деньги, если не удалось найти работу.

Источник

Prettier, ESLint, Husky, Lint-Staged и EditorConfig: инструменты для написания аккуратного кода

Вы стремитесь к тому, чтобы писать аккуратный код, но не знаете с чего начать… Вы вчитываетесь в руководства по стилю, вроде этого от Airbnb, стараетесь следовать практическим рекомендациям ведущих специалистов… Вам приходится удалять неиспользуемый код? Приходится искать ненужные переменные? Вы пытаетесь выявлять неудачные паттерны, применённые в ваших программах? Например — хотите понять, читая хитросплетения кода некоей функции, возвратит ли она что-нибудь или нет. Звучит знакомо? Проблема заключается в том, что программисту очень тяжело и многое успевать, и многому учиться.

Может быть вы — тимлид, под началом которого трудится команда разработчиков разного уровня? В вашей команде есть новые люди? Беспокоит ли вас то, что код, который они напишут, не будет соответствовать вашим стандартам? Проходят ли ваши дни в проверках чужого кода, когда эти проверки, в основном, касаются соблюдения стандартов, а не программной логики?

Автор этого материала говорит, что он сталкивался со всем тем, чему посвящены только что заданные вопросы. То, с чем он столкнулся, утомляет и изматывает. Здесь он хочет рассказать об инструментах, правильное применение которых позволяет решить вышеописанные проблемы.

А именно, здесь пойдёт речь о таких средствах как Prettier, ESLint, Husky, Lint-Staged, EditorConfig, об автоматизации форматирования и линтинга кода. Этот материал ориентирован, в основном, на React-разработку, но рассмотренные здесь принципы можно применить в любом веб-проекте. Вот репозиторий, где, кроме прочего, собрано то, о чём тут пойдёт речь.

Prettier

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

Prettier форматирует код, следуя правилам

▍Сильные стороны Prettier

Вот какие возможности и особенности Prettier позволяют говорить о полезности этого инструмента:

▍Настройка Prettier

Установим пакет prettier в качестве зависимости разработки нашего проекта:

Благодаря этой команде в package.json будет добавлена запись о зависимости разработки, которая выглядит так:

В этот файл внесём следующий код (именно в таком вот неприглядном виде):

Как это исправить? Существует три подхода к работе с плохо отформатированным кодом:

Разберём эти правила:

Вот что произойдёт, если оно установлено в значение false :

Теперь, когда правила настроены, поговорим об этом скрипте:

Запустим скрипт из командной строки:

Вот что стало после этого с показанным выше плохо отформатированным кодом.

Результат форматирования кода с помощью Prettier

На этом будем считать, что с Prettier мы разобрались. Поговорим о линтерах.

ESLint

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

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

▍Зачем нужен линтер для JavaScript?

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

Линтеры, наподобие ESLint, позволяют разработчикам находить проблемы в коде, не запуская его.

▍Почему ESLint — это особенный инструмент?

В заголовок этого раздела вынесен хороший вопрос. Дело тут в том, что ESLint поддерживает плагины. Так, правила проверки кода не должны представлять собой монолитный пакет. Всё, что нужно, можно подключать по мере необходимости. Каждое добавляемое в систему правило линтинга автономно, оно может быть, независимо от других, включено или выключено. Каждому правилу можно назначить уровень оповещения в соответствии с желанием разработчика — это может быть предупреждение (warning) или ошибка (error).

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

Среди существующих руководств по стилю JavaScript можно отметить следующие, весьма популярные:

Это руководство активно поддерживается — взгляните на его репозиторий на GitHub. Здесь я буду использовать набор правил, основанный именно на нём.

Поэтому обсудим роль представленных здесь пакетов:

Этот файл имеет следующую структуру:

Рассмотрим блоки этого файла, представленные объектами с соответствующими именами:

Здесь заданы три папки:

Запуск скрипта lint

Если выполнить второй скрипт ( yarn lint:write ), то ESLint выполнит такую же проверку, которая была выполнена раньше. Единственное различие заключается в том, что в таком режиме система попытается исправить обнаруженные ошибки, постарается привести код в как можно более пристойный вид.

Расширение ESLint для VS Code

У нас уже есть настроенные Prettier и ESLint, но, чтобы пользоваться возможностями этих инструментов, нам приходится запускать скрипты. Это не очень-то удобно, поэтому попробуем это исправить. А именно, мы хотим добиться того, чтобы форматирование и линтинг кода выполнялись бы по команде сохранения файла в редакторе. Кроме того, выполнять линтинг и форматирование кода мы хотим перед выполнением коммитов.

Рассмотрим его содержимое.

Представьте свои ощущения, если бы к вам попал код проекта размером в 20000 строк, который вам надо было бы проверить и улучшить. А теперь представьте себе, что вам пришлось бы это делать вручную. Такая работа заняла бы, наверное, месяц. А с помощь вышеописанных средств автоматизации всё это делается секунд за тридцать.

Теперь, после настройки всего необходимого, каждый раз, когда вы сохраняете файл с кодом, редактор сам позаботится о проверке и форматировании текста программы. Однако тут мы говорим о редакторе VS Code. Вполне возможно, что кто-то в вашей команде предпочитает какой-нибудь другой редактор. Ничего плохого в этом нет, но, чтобы всем удобно было работать, нам придётся позаниматься ещё кое-что автоматизировать.

Husky

Пакет Husky позволяет задействовать хуки Git. Это означает, что у вас появляется возможность выполнять некие действия перед выполнением коммита или перед отправкой кода репозиторий.

Для того чтобы воспользоваться возможностями Husky, сначала установим этот пакет:

После этого добавим в package.json следующее:

Это приведёт к тому, что перед выполнением команды commit или push будет вызван некий скрипт, который, например, выполняет тестирование кода или его форматирование.

Подробности о Husky можно почитать здесь.

Lint-staged

Пакет Lint-staged позволяет проверять с помощью линтера индексированные файлы, что помогает предотвратить отправку в репозиторий кода с ошибками.

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

Lint-staged позволяет выполнять набор произвольных задач над индексированными файлами, отфильтрованными по шаблону поиска. Подробности об этом можно почитать здесь.

Установим пакет Lint-staged:

Совместное использование Husky и Lint-staged

Приведём снова, для удобства, содержимое нашего package.json :

Теперь, зная о Husky и Lint-staged, вы можете оценить их влияние на работу с Git. А именно, предположим, что были выполнены следующие команды:

Теперь вы знаете о том, как интегрировать Prettier, ESLint, Husky и Lint-staged в свой проект.

На сайте проекта можно найти список редакторов, которые поддерживают этот файл. В него, в частности, входят WebStorm, AppCode, Atom, Eclipse, Emacs, BBEdit и другие.

Поясним настройки, использованные в этом файле:

Итоги

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

Уважаемые читатели! Какими инструментами вы пользуетесь для проверки и форматирования кода? Как автоматизируете эти процессы?

Источник

Почему Преттье не форматирует код в VSCODE?

В моем приложении Nuxt, где ESlint и Prettier установлены и включены, я переключился на редактор кода Visual Studio.

Когда я открываю файл .vue, нажимаю CMD + Shift + P и выбираю » Формат документа», мой файл вообще не форматируется.

Мои настройки .prettierrc:

У меня так много строк исходного кода, что я не могу отформатировать их вручную. Что я делаю неправильно?

32 ответа

Как я разобрался после огромного разочарования из-за того, что Prettier перестал работать в VSCode.

Это волшебным образом решило мою проблему.

В зависимости от вашего случая это может вам помочь.

Если выполнение того, что упомянул @Simin Maleki, не решит эту проблему для вас, есть вероятность, что ваш форматтер по умолчанию не установлен:

Убедитесь, что ваш Editor: Default Formatter поле не null скорее esbenp.prettier-vscode и что отмечены все указанные ниже языки. Это устранило мою проблему.

Prettier также может форматировать ваши файлы при сохранении.

Однако установка и включение не приводят к работе.

Вы должны проверить «форматировать при сохранении» в VSCode: Настройка >> Пользователь >> Текстовый редактор >> Форматирование

Иногда prettier перестает работать, когда в коде есть синтаксические ошибки. Вы можете просмотреть ошибки, нажав кнопку x в правом нижнем углу рядом с Prettier.

отключить и включить prettier расширение решает мою проблему

Я не использую Vue, но возникла та же проблема.

У меня уже были настройки

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

Я не знаю почему Editor: Format on Save установлен в true было недостаточно. Мне нужно было выбрать модуль форматирования по умолчанию, используя описанные выше шаги, чтобы он работал.

Я столкнулся с этой проблемой, и эти три шага решили мою проблему:

Вы можете попробовать добавить этот раздел в свой файл пользовательских настроек?

prettier.disableLanguages ​​(по умолчанию: [«vue»])

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

Затем я понял, что экспериментально установил Format On Save Mode на modification а не об этом и забыл. Это привело к тому, что в файлах HTML ничего не отформатировалось, и, что удивительно, даже мои изменения. Вернемся к file решил вопрос.

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

При нажатии на этот статус панель вывода должна сообщить о проблеме в файле HTML. Для меня проблема заключалась в том, что у меня был div внутри тега ap, против которого, как я полагаю, выступают соглашения prettier / VSCode. Когда я удалил его (и в сочетании со всеми вышеперечисленными настройками, а именно форматировщиком по умолчанию и форматированием при сохранении ), я стал лучше работать.

.prettierrc не требуется, если вы не хотите переопределить настройки VSCode.

Включение «форматирования при сохранении» в VSCode: Настройка >> Пользователь >> Текстовый редактор >> Форматирование у меня сработало!

Для меня это было связано с ESlint, который также работает с Prettier. Eslint не работал (конфликт локальной установки и глобальной установки), что сломало Prettier.

Если Prettier автоматически форматирует все остальные файлы, кроме файлов HTML, при сохранении:

Нажмите Cmd + P или же Ctrl + P чтобы открыть палитру команд, введите в нее следующий текст:

Нажмите на Preferences: Open Settings (JSON) из раскрывающегося списка предложений. Внутри файла проверьте, существует ли ключ. Если ключ существует и его значение указывает на использование другого расширения форматирования, установленного в Visual Studio Code, вам следует сбросить его, чтобы использовать Prettier.

Источник

Prettier в крупных проектах: тратим 20 минут на настройку, забываем о форматировании навсегда

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

Год назад одна из команд в Skyeng сталкивалась с такими холиварами почти на каждом ревью. Но затем человек, у которого больше всех болело, сказал: «Теперь живем на Prettier’e, согласны?» За следующие месяцы ребята ни разу не поднимали вопрос о форматировании, а теперь эта штука стоит на всем монорепозитории фронтенда — и его использует каждая команда, которая туда заезжает.

Prettier – инструмент для автоформатирования кода с поддержкой кучи инструментов, включая наши любимые Angular и Typescript. Он не модифицирует код, не заменяет тернарные операторы на if’ы и не разбивает длинные строки на несколько конкатенированных (об этом уже должен думать разработчик), а просто выводит то, что есть, с нужным форматированием.

Как было раньше

На тот момент в Skyeng было уже несколько десятков разработчиков, и каждый месяц могли приходить по 10-20 новичков. Все работали (и работают) в небольших командах — каждая, фактически, считается независимой “боевой единицей” со своими задачами и договоренностями.

Давайте представим одну такую — безусловно, все совпадения случайны, — команду:

Борис – миддл, который пришёл к нам из другой большой компании. У них был свой стайл-гайд, но он старается переучиться на наш: в целом, справляется, но время от времени делает что-то по части форматирования не так и узнаёт об этом только на код-ревью. Мелочь, но неприятно.

Павел – более опытный разработчик. Знает своё дело, всегда выполняет задачи качественно и в срок, но иногда напрочь забывает про договоренности и пишет по-своему. В итоге его код не вписывается в большой проект, хоть и написан качественно и со вкусом.

Артур – перфекционист с философией «чистый код – понятный код»: вечно парится по поводу код-стайла. Безусловно, отклонит код коллег с кучей комментов «здесь перенесите фигурную скобочку на следующую строчку» — и Борис потратит время на правки, а Павел – на споры уровня «тебе не нравится, ты и меняй».

Как стало

Задача Prettier – заставить разработчика не думать о форматировании: в нем минимум настроек. Это и подкупило Павла, когда Артур кинул в чат команды ссылку на проект:

— поставил сам Prettier,
— поставил пре-коммит хук (подробнее),
— оставил в чате пару комментариев, что код-стайл там свой (например, логические операции в if’ах ставятся в конце строки, а не в начале).

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

Даже если бы это было написано в одну строку, оно всё равно бы переформатировалось так, как надо:

Ещё кусочек кода, уже без точек с запятой. До:

Теперь код-ревью проходит быстрее, Борис не тратит кучу рабочего времени на форматирование уже написанного кода, Павел продолжает писать так, как и писал (но теперь с ним никто не ругается), а Артур наконец-то доволен, заходя в репозиторий и улыбаясь от красоты кода. Используя простой инструмент с февраля 2019-го, ребята сэкономили кучу времени, перестав спорить из-за форматирования. А затем убедили остальные команды сделать так же.

Источник