Ferramenta de Formatação JavaScript
O que é Formatação JavaScript?
O formatador JavaScript transforma código JavaScript em uma forma consistente e legível. Ele organiza indentação, quebras de linha, blocos, objetos literais, arrays, chamadas de função e expressões aninhadas para que lógica e fluxo de dados sejam mais fáceis de acompanhar. Ajuda em depuração, revisão de código, exemplos de estudo, trechos colados e arquivos minificados ou gerados. Formatação não é análise estática: não corrige erros de execução, não prova que lógica assíncrona está correta, não detecta toda dependência insegura nem substitui linting. Em projetos reais, a saída deve combinar com ESLint, Prettier ou convenções da equipe.
Como Usar
Como usar
- Cole ou digite o código JavaScript na caixa de entrada à esquerda
- Selecione o tamanho da indentação, o estilo de aspas e as configurações de ponto e vírgula
- Clique em 'Formatar' para embelezar o código ou em 'Validar' para verificar a sintaxe
- Veja os resultados à direita (com destaque de sintaxe)
- Clique em 'Copiar' para copiar para a área de transferência
Descrição das Opções
Atalhos de Teclado
- Ctrl + EnterFormatar
- Ctrl + Shift + CCopiar resultado
Dicas de JavaScript
- A formatação não comprova a correção em tempo de execução. Execute novamente os testes ou as verificações no navegador após alterar JavaScript que dependa de inserção automática de ponto e vírgula ou de transformações de build.
- Ao validar código colado, lembre-se de que o suporte do parser do navegador pode diferir do seu runtime de destino ou da configuração do bundler.
Casos de uso
Princípio técnico
Um embelezador de JavaScript é um pipeline de três estágios definido com base na gramática ECMA-262: um lexer produz um fluxo de tokens de IdentifierName, NumericLiteral, StringLiteral, TemplateHead/Middle/Tail, Punctuator, Keyword e LineTerminator; um parser constrói uma AST compatível com ESTree (a estrutura usada por @babel/parser, acorn e esprima); um printer percorre a árvore e emite texto por regras guiadas pelo tamanho da indentação e largura de impressão alvo. O Prettier compila a AST em uma representação intermediária Doc construída a partir dos primitivos group, indent, line e softline, e então um algoritmo de layout escolhe pontos de quebra para que a saída caiba no printWidth (80, 100, 120). O ESLint --fix, por sua vez, reescreve tokens in-place no código original, preservando comentários de forma mais agressiva, mas corrigindo apenas regras que optaram pelo autofix. O printer não pode inserir quebras de linha livremente: a ECMA-262 §11.9.1 Automatic Semicolon Insertion encerra uma instrução em qualquer LineTerminator, a menos que o próximo token seja uma continuação. Concretamente, quebrar uma linha antes de uma que comece com `(`, `[`, `` ` ``, `+`, `-`, `/` ou um token `++`/`--` mudará silenciosamente a semântica, e uma quebra de linha diretamente após `return`, `throw`, `break`, `continue` ou `yield` insere um ponto e vírgula e descarta o operando. Template literals (backticks) preservam seus bytes internos literalmente, incluindo expressões `${}` embutidas cujo interior é reformatado como JS, mas cujos espaços em branco circundantes não são. Comentários são reassociados a nós vizinhos da AST por meio dos arrays leading/trailing/innerComments, de modo que sobrevivem à conversão. O lexer e o printer são ambos O(n) em relação ao tamanho do código com uma constante pequena; o parser é efetivamente linear para código bem-formado graças ao lookahead de token único na gramática ECMA-262 no estilo LR(1). A análise padrão de JavaScript não cobre JSX, anotações de tipo TypeScript, decorators ou Flow, que exigem plugins do @babel/parser ou @typescript-eslint/parser; executar ferramentas de JS puro em um arquivo .tsx rejeitará anotações `: type`. Source maps (Source Map v3) podem preservar o mapeamento original de linha/coluna quando uma etapa de build precisa manter a fidelidade do stack trace, e as terminações de linha (LF vs CRLF) são normalizadas no momento da escrita, não no momento da análise.
- Pipeline: lexer (fluxo de tokens conforme ECMA-262 §12) -> AST ESTree (acorn/@babel/parser/esprima) -> printer; lexer e printer são O(n), parser O(n) com lookahead de token único.
- Armadilhas de ASI da ECMA-262 §11.9.1: nunca quebre uma linha antes de um token que comece com `(`, `[`, `` ` ``, `+`, `-`, `/`, ou antes de `++`/`--`, e nunca quebre imediatamente após `return`/`throw`/`break`/`continue`/`yield`.
- Prettier vs ESLint --fix: o Prettier reduz a AST para uma IR Doc (group/indent/line) e escolhe layouts que cabem no printWidth (80/100/120); o ESLint --fix reescreve tokens in-place e aplica apenas regras marcadas com fixer.
- Preservação de comentários: leading/trailing/innerComments são vinculados a nós da AST; blocos JSDoc imediatamente acima de declarações são mantidos anexados para que o printer não os deixe órfãos em uma instrução anterior.
- Template literals (backticks) são preservados byte a byte; apenas o JS dentro de `${}` é reimpresso. Literais regex e aspas de string literals são normalizados para o estilo de aspas simples/duplas escolhido, com escapes `\` recalculados.
- Cobertura de dialeto: parsers JS puro rejeitam JSX, tipos TypeScript, decorators e Flow; arquivos .tsx/.ts precisam de plugins do @babel/parser ['jsx','typescript','decorators-legacy'] ou @typescript-eslint/parser.
- Normalização da saída: terminações de linha escritas como LF ou CRLF conforme configuração (independente da entrada), política de vírgula final aplicada a arrays/objects/calls multilinha, e Source Map v3 emitido quando a cadeia de ferramentas precisa reter informações originais de linha/coluna.
Exemplos
Antes da formatação
function greet(name){if(!name){return 'Hello, stranger';}const greeting=`Hello, ${name}!`;console.log(greeting);return greeting;}Após formatação (2 espaços)
function greet(name) {
if (!name) {
return 'Hello, stranger';
}
const greeting = `Hello, ${name}!`;
console.log(greeting);
return greeting;
}Após minificação
function greet(n){if(!n)return"Hello, stranger";const e=`Hello, ${n}!`;return console.log(e),e}Perguntas frequentes
Qual estilo o formatador usa?
A maioria das versões usa o Prettier com configurações padrão: largura de linha de 80 colunas, ponto e vírgula, aspas duplas, indentação de 2 espaços e vírgulas finais quando válidas em ES5. Altere as opções se seu projeto usar um estilo diferente. O resultado é determinístico para uma mesma configuração — mesma entrada, mesma saída.
Ele executa meu JS?
Não. Ele apenas faz o parse e reimprime o código-fonte. Efeitos colaterais, chamadas de rede e erros em tempo de execução são irrelevantes — o formatador nunca executa o script.
Ele corrige erros de sintaxe?
Não. O parser se recusa a formatar JavaScript inválido e mostra onde o parse falhou. Corrija o erro de sintaxe primeiro; causas comuns são chaves ou parênteses faltando, ponto e vírgula ausente após um return de IIFE, ou template literals com crases desbalanceadas.
Há suporte para JSX/TypeScript?
A maioria das versões modernas faz parse de JavaScript com sintaxe JSX e TypeScript (.ts, .tsx). O formatador detecta qual sintaxe usar com base no que consegue analisar. Se você está trabalhando com ES5 puro, desative o modo TypeScript para evitar falsos positivos de erro.
Ele consegue minificar JS?
Algumas versões oferecem um modo de minificação (estilo Terser) que renomeia variáveis, remove espaços em branco e elimina código morto. A saída é pequena, porém ilegível. Use minificação para builds de produção e formatação para revisão de código-fonte.
Meu código é enviado para algum servidor?
Não. O parse e a impressão rodam no seu navegador usando um parser baseado em JavaScript. O código colado não é transmitido.
Por que meus comentários ficaram um pouco deslocados?
O Prettier e formatadores semelhantes associam os comentários ao nó da AST mais próximo. Um comentário entre duas funções pode 'pertencer' à função abaixo na AST e acabar sendo reanexado a ela. Comentários inline ao final da linha geralmente são preservados exatamente; os flutuantes podem se mover.