Инструмент форматирования JavaScript
Что такое форматирование JavaScript?
JavaScript Formatter приводит JavaScript-код к единообразному и читаемому виду. Он упорядочивает отступы, переносы строк, блоки, объектные литералы, массивы, вызовы функций и вложенные выражения, чтобы логику и поток данных было легче отслеживать. Это помогает при отладке, ревью, учебных примерах, вставленных фрагментах, минифицированных и сгенерированных файлах. Форматирование не является статическим анализом: оно не исправляет runtime-ошибки, не доказывает корректность асинхронной логики, не находит все небезопасные зависимости и не заменяет linting. В реальных проектах результат должен совпадать с ESLint, Prettier или командными правилами. Перед коммитом полезно сравнить diff отдельно. Для production-данных или кодовой базы результат все равно нужно проверить parser, тестами или правилами проекта.
Как использовать
Как использовать
- Вставьте или введите JavaScript-код в левое поле ввода
- Выберите размер отступа, стиль кавычек и настройки точек с запятой
- Нажмите «Format» для форматирования кода или «Validate» для проверки синтаксиса
- Просмотрите результаты справа (с подсветкой синтаксиса)
- Нажмите «Copy» для копирования в буфер обмена
Описание опций
Горячие клавиши
- Ctrl + EnterФорматировать
- Ctrl + Shift + CКопировать результат
Советы по JavaScript
- Форматирование не доказывает корректность выполнения. Перезапустите тесты или проверки в браузере после изменения JavaScript, который зависит от автоматической вставки точек с запятой или сборочных преобразований.
- При проверке вставленного кода помните, что поддержка парсера браузера может отличаться от вашей целевой среды выполнения или конфигурации сборщика.
Применение
Технический принцип
Pretty-printer JavaScript представляет собой трёхэтапный конвейер, определённый на основе грамматики ECMA-262: лексический анализатор (lexer) создаёт поток токенов IdentifierName, NumericLiteral, StringLiteral, TemplateHead/Middle/Tail, Punctuator, Keyword и LineTerminator; синтаксический анализатор строит AST, совместимое с ESTree (формат, используемый @babel/parser, acorn и esprima); принтер обходит дерево и генерирует текст по правилам, управляемым размером отступа и целевой шириной печати. Prettier компилирует AST в промежуточное представление Doc, построенное из примитивов group, indent, line и softline, затем алгоритм компоновки выбирает точки переноса так, чтобы результат вписывался в printWidth (80, 100, 120). ESLint --fix, напротив, перезаписывает токены непосредственно в исходном коде, более агрессивно сохраняя комментарии, но исправляя только те правила, которые помечены для автозамены. Принтер не может свободно вставлять переносы строк: ECMA-262 §11.9.1 Automatic Semicolon Insertion завершает инструкцию на любом LineTerminator, если следующий токен не является продолжением. Конкретно, перенос перед строкой, начинающейся с `(`, `[`, `` ` ``, `+`, `-`, `/` или токена `++`/`--`, незаметно изменит семантику, а новая строка сразу после `return`, `throw`, `break`, `continue` или `yield` вставит точку с запятой и отбросит операнд. Шаблонные строки (backticks) сохраняют своё содержимое побайтово, включая встроенные выражения `${}`, которые переформатируются как JS, но окружающие пробелы не трогаются. Комментарии привязываются к соседним узлам AST через массивы leading/trailing/innerComments, чтобы пережить round-trip. Лексический анализ и генерация текста оба работают за O(n) по длине исходного кода с малой константой; парсер линеен для корректного кода благодаря одно-токеновому lookahead в грамматике ECMA-262 стиля LR(1). Стандартный парсинг JavaScript не покрывает JSX, аннотации типов TypeScript, декораторы или Flow — для этого нужны плагины @babel/parser или @typescript-eslint/parser; запуск инструментов для обычного JS над .tsx файлом отвергнет аннотации `: type`. Source maps (Source Map v3) сохраняют соответствие строк/столбцов оригинала, когда сборочный шаг должен поддерживать точность стектрейсов, а окончания строк (LF vs CRLF) нормализуются при записи, а не при парсинге.
- Конвейер: лексический анализатор (поток токенов по ECMA-262 §12) -> ESTree AST (acorn/@babel/parser/esprima) -> принтер; лексер и принтер работают за O(n), парсер — O(n) с одно-токеновым lookahead.
- Ловушки ASI из ECMA-262 §11.9.1: никогда не разрывайте строку перед токеном, начинающимся с `(`, `[`, `` ` ``, `+`, `-`, `/` или перед `++`/`--`, и никогда не разрывайте сразу после `return`/`throw`/`break`/`continue`/`yield`.
- Prettier vs ESLint --fix: Prettier опускает AST в промежуточное представление Doc (group/indent/line) и выбирает компоновки, вписывающиеся в printWidth (80/100/120); ESLint --fix перезаписывает токены на месте и применяет только правила с тегом fixer.
- Сохранение комментариев: leading/trailing/innerComments привязаны к узлам AST; блоки JSDoc непосредственно над объявлениями остаются прикреплёнными, чтобы принтер не отрывал их от предыдущей инструкции.
- Шаблонные строки (backticks) сохраняют побайтово; только JS внутри `${}` переформатируется. Литералы регулярных выражений и кавычки строковых литералов нормализуются к выбранному стилю одинарных/двойных кавычек с пересчётом `\`-экранирования.
- Покрытие диалектов: обычные JS-парсеры отвергают JSX, типы TypeScript, декораторы и Flow; для .tsx/.ts файлов нужны плагины @babel/parser ['jsx','typescript','decorators-legacy'] или @typescript-eslint/parser.
- Нормализация вывода: окончания строк записываются как LF или CRLF по конфигурации (независимо от ввода), политика trailing-запятых применяется к многострочным массивам/объектам/вызовам, а Source Map v3 генерируется, когда инструментальной цепочке нужно сохранить исходные строки/столбцы.
Примеры
До форматирования
function greet(name){if(!name){return 'Hello, stranger';}const greeting=`Hello, ${name}!`;console.log(greeting);return greeting;}После форматирования (2 пробела)
function greet(name) {
if (!name) {
return 'Hello, stranger';
}
const greeting = `Hello, ${name}!`;
console.log(greeting);
return greeting;
}После минификации
function greet(n){if(!n)return"Hello, stranger";const e=`Hello, ${n}!`;return console.log(e),e}Часто задаваемые вопросы
Какой стиль использует форматтер?
В большинстве сборок используется Prettier с настройками по умолчанию: ширина строки 80 символов, точки с запятой, двойные кавычки, отступ в 2 пробела, висячие запятые там, где это допустимо ES5. Переключите параметры, если в проекте принят другой стиль. Результат детерминирован для заданной конфигурации — одинаковый ввод даёт одинаковый вывод.
Запускает ли он мой JS?
Нет. Он только разбирает и заново печатает исходный код. Побочные эффекты, сетевые вызовы и ошибки выполнения не имеют значения — форматтер никогда не выполняет скрипт.
Исправит ли он синтаксические ошибки?
Нет. Парсер отказывается форматировать невалидный JavaScript и показывает, где разбор не удался. Сначала исправьте синтаксическую ошибку; типичные причины — пропущенные скобки, отсутствие точки с запятой после возврата из IIFE или шаблонные литералы с непарными обратными кавычками.
Поддерживается ли JSX/TypeScript?
Большинство современных сборок разбирают JavaScript с синтаксисом JSX и TypeScript (.ts, .tsx). Форматтер определяет синтаксис по тому, что ему удалось разобрать. Если вы пишете на чистом ES5, отключите режим TypeScript, чтобы избежать ложноположительных ошибок.
Может ли он минифицировать JS?
Некоторые сборки предлагают режим минификации (в стиле Terser), который переименовывает переменные, удаляет пробелы и устраняет мёртвый код. Вывод компактен, но нечитаем. Используйте минификацию для продакшен-сборок, а форматирование — для код-ревью.
Загружается ли мой код куда-либо?
Нет. Разбор и печать выполняются в вашем браузере с помощью парсера на JavaScript. Вставленный код никуда не передаётся.
Почему мои комментарии слегка сдвинулись?
Prettier и подобные форматтеры привязывают комментарии к ближайшему узлу AST. Комментарий между двумя функциями в AST может «принадлежать» нижней функции и оказаться переприкреплённым. Завершающие строчные комментарии обычно сохраняются в точности; «плавающие» могут сместиться.