Herramienta de Formato JavaScript
¿Qué es el Formateo de JavaScript?
El formateador JavaScript convierte código JavaScript en una forma coherente y legible. Organiza indentación, saltos de línea, bloques, objetos literales, arrays, llamadas a funciones y expresiones anidadas para que la lógica y el flujo de datos sean más fáciles de seguir. Ayuda en depuración, revisión de código, ejemplos de aprendizaje, fragmentos pegados y archivos minificados o generados. El formateo no es análisis estático: no corrige errores de ejecución, no demuestra que la lógica asíncrona sea correcta, no detecta todas las dependencias inseguras ni sustituye al linting. En proyectos reales debe alinearse con ESLint, Prettier o las convenciones del equipo.
Cómo usar
Cómo usar
- Pega o escribe código JavaScript en el cuadro de entrada izquierdo
- Selecciona el tamaño de sangría, el estilo de comillas y el uso de punto y coma
- Pulsa 'Formatear' para embellecer el código o 'Validar' para comprobar la sintaxis
- Consulta los resultados a la derecha (con resaltado de sintaxis)
- Pulsa 'Copiar' para copiarlo al portapapeles
Descripción de opciones
Atajos de teclado
- Ctrl + EnterFormat
- Ctrl + Shift + CCopiar resultado
Consejos de JavaScript
- El formateo no garantiza la corrección en tiempo de ejecución. Vuelve a ejecutar las pruebas o las comprobaciones del navegador tras modificar JavaScript que dependa de la inserción automática de punto y coma o de transformaciones de build.
- Al validar código pegado, recuerda que el soporte del analizador del navegador puede diferir del runtime o la configuración de bundler objetivo.
Casos de uso
Principio técnico
Un pretty-printer de JavaScript es una tubería de tres fases definida según la gramática de ECMA-262: un lexer produce un flujo de tokens (IdentifierName, NumericLiteral, StringLiteral, TemplateHead/Middle/Tail, Punctuator, Keyword y LineTerminator); un parser construye un AST compatible con ESTree (la estructura usada por @babel/parser, acorn y esprima); un printer recorre el árbol y emite texto siguiendo reglas determinadas por el tamaño de sangría y el ancho de impresión objetivo. Prettier compila el AST en una representación intermedia Doc construida con los primitivos group, indent, line y softline; luego un algoritmo de disposición elige los puntos de corte para que la salida se ajuste a printWidth (80, 100, 120). ESLint --fix, en cambio, reescribe los tokens directamente sobre el código fuente original, preservando los comentarios de forma más agresiva pero solo corrigiendo las reglas que optan por la corrección automática. El printer no puede insertar saltos de línea libremente: la sección ECMA-262 §11.9.1 sobre Inserción Automática de Punto y Coma (ASI) finaliza una sentencia en cualquier LineTerminator a menos que el siguiente token sea una continuación. En concreto, romper antes de una línea que comience con `(`, `[`, `` ` ``, `+`, `-`, `/` o un token `++`/`--` cambiará la semántica silenciosamente, y un salto de línea justo después de `return`, `throw`, `break`, `continue` o `yield` inserta un punto y coma y descarta el operando. Los template literals (backticks) preservan sus bytes interiores de forma literal, incluidas las expresiones `${}` incrustadas cuyo interior se reformatea como JS pero cuyo espacio en blanco circundante no se modifica. Los comentarios se reasocian a los nodos AST vecinos mediante los arrays leading/trailing/innerComments para que sobrevivan al proceso de ida y vuelta. El lexing y el printing son ambos O(n) sobre la longitud del código fuente con una constante pequeña; el parser es efectivamente lineal para código bien formado gracias a la anticipación de un solo token en la gramática LR(1) de ECMA-262. El parsing estándar de JavaScript no cubre JSX, anotaciones de tipo de TypeScript, decoradores ni Flow, que requieren plugins de @babel/parser o @typescript-eslint/parser; ejecutar herramientas de JS puro sobre un archivo .tsx rechazará las anotaciones `: type`. Los source maps (Source Map v3) pueden preservar la correspondencia original de línea/columna cuando un paso de compilación necesita mantener la fidelidad del stack trace, y los finales de línea (LF vs CRLF) se normalizan en el momento de escritura, no en el de análisis.
- Tubería: lexer (flujo de tokens según ECMA-262 §12) -> AST ESTree (acorn/@babel/parser/esprima) -> printer; el lexer y el printer son O(n), el parser es O(n) con anticipación de un solo token.
- Trampas de ASI de ECMA-262 §11.9.1: nunca romper una línea antes de un token que comience con `(`, `[`, `` ` ``, `+`, `-`, `/`, o antes de `++`/`--`, y nunca romper inmediatamente después de `return`/`throw`/`break`/`continue`/`yield`.
- Prettier vs ESLint --fix: Prettier convierte el AST a un IR Doc (group/indent/line) y elige disposiciones que se ajusten a printWidth (80/100/120); ESLint --fix reescribe los tokens in situ y solo aplica reglas marcadas como corregibles.
- Preservación de comentarios: leading/trailing/innerComments se vinculan a los nodos AST; los bloques JSDoc justo encima de las declaraciones se mantienen unidos para que el printer no los deje huérfanos en una sentencia anterior.
- Los template literals (backticks) se preservan a nivel de bytes; solo el JS dentro de `${}` se vuelve a imprimir. Los literales regex y las comillas de literales de cadena se normalizan al estilo de comillas simples/doble elegido con los escapes `\` recalculados.
- Cobertura de dialectos: los parsers de JS puro rechazan JSX, tipos de TypeScript, decoradores y Flow; los archivos .tsx/.ts necesitan plugins de @babel/parser ['jsx','typescript','decorators-legacy'] o @typescript-eslint/parser.
- Normalización de salida: los finales de línea se escriben como LF o CRLF según la configuración (independiente de la entrada), la política de comas finales se aplica a arrays/objetos/llamadas multilínea, y se emite Source Map v3 cuando la cadena de herramientas necesita retener la información original de línea/columna.
Ejemplos
Antes de formatear
function greet(name){if(!name){return 'Hello, stranger';}const greeting=`Hello, ${name}!`;console.log(greeting);return greeting;}Después de formatear (2 espacios)
function greet(name) {
if (!name) {
return 'Hello, stranger';
}
const greeting = `Hello, ${name}!`;
console.log(greeting);
return greeting;
}Después de minificar
function greet(n){if(!n)return"Hello, stranger";const e=`Hello, ${n}!`;return console.log(e),e}Preguntas frecuentes
¿Qué estilo usa el formateador?
La mayoría de las versiones usan Prettier con la configuración predeterminada: ancho de línea de 80 columnas, punto y coma, comillas dobles, sangría de 2 espacios y comas finales donde sean válidas en ES5. Cambia las opciones si tu proyecto usa un estilo distinto. El resultado es determinista para una configuración dada: misma entrada, misma salida.
¿Ejecuta mi JS?
No. Solo analiza y reimprime el código fuente. Los efectos secundarios, las llamadas de red y los errores en tiempo de ejecución son irrelevantes: el formateador nunca ejecuta el script.
¿Corregirá errores de sintaxis?
No. El parser se niega a formatear JavaScript inválido y muestra dónde falló el análisis. Corrige primero el error de sintaxis; las causas habituales son corchetes ausentes, punto y coma faltante tras un return en un IIFE, o template literals con backticks descompensados.
¿Se admiten JSX y TypeScript?
La mayoría de las versiones modernas analizan JavaScript con sintaxis JSX y TypeScript (.ts, .tsx). El formateador detecta la sintaxis según lo que analice. Si trabajas con ES5 puro, desactiva el modo TypeScript para evitar falsos positivos.
¿Puede minificar JS?
Algunas versiones ofrecen un modo minify (estilo Terser) que renombra variables, elimina espacios en blanco y descarta código muerto. La salida es pequeña pero ilegible. Usa minificación para builds de producción y formateo para revisar el código fuente.
¿Se sube mi código?
No. El análisis y la impresión se ejecutan en tu navegador con un parser basado en JavaScript. El código pegado no se transmite.
¿Por qué mis comentarios se desplazan ligeramente?
Prettier y formateadores similares vinculan los comentarios al nodo del AST más cercano. Un comentario entre dos funciones podría 'pertenecer' en el AST a la función de abajo y acabar reasignado allí. Los comentarios al final de línea suelen conservarse exactamente; los flotantes pueden moverse.