Saltar al contenido principal

Prettier 1.15: Soporte para HTML, Vue, Angular y MDX

· 31 min de lectura
Ika
Ika
Traducción Beta No Oficial

Esta página fue traducida por PageTurner AI (beta). No está respaldada oficialmente por el proyecto. ¿Encontraste un error? Reportar problema →

Esta versión añade soporte para HTML, Vue, Angular y MDX. También respeta la posición de los decoradores, añade una opción para comillas simples en JSX, permite inferir el parser mediante shebang, incorpora soporte para nuevas características de sintaxis y realiza algunos ajustes de formato.

Destacados​

HTML/Vue/Angular​

Soporte para HTML, Vue y Angular (#5259 por @ikatyang, #4753 por @evilebottnawi, #2083 por @azz)​

¡Prettier ahora puede formatear archivos HTML, Vue y Angular! 🎉

Usamos angular-html-parser, un parser HTML extraído de Angular, para analizar estos archivos HTML y plantillas HTML, por lo que debería ser altamente compatible con la especificación HTML gracias al equipo de Angular.

Algunos aspectos destacados:

Formateo sensible a espacios en blanco​

Como habrás notado al trabajar con HTML, los siguientes dos casos no producen la misma salida:

htmloutput
with spaces1<b> 2 </b>31 2 3
without spaces1<b>2</b>3123

Esto ocurre porque los espacios en blanco son significativos en elementos inline.

Por esta razón, no podemos formatear con seguridad

<a href="https://prettier.io/">Prettier is an opinionated code formatter.</a>

en

<a href="https://prettier.io/">
  Prettier is an opinionated code formatter.
</a>

ya que podría modificar la salida visualizada en el navegador.

En lugar de romper tu código o no hacer nada, introducimos el formateo sensible a espacios en blanco, que:

  • sigue el valor predeterminado de CSS display para cada elemento e identifica si los espacios en blanco dentro de él son significativos,

  • y envuelve las etiquetas de manera que evita agregar o eliminar espacios en blanco significativos.

Por ejemplo:

<!-- <span> is an inline element, <div> is a block element -->

<!-- input -->
<span class="dolorum atque aspernatur">Est molestiae sunt facilis qui rem.</span>
<div class="voluptatem architecto at">Architecto rerum architecto incidunt sint.</div>

<!-- output -->
<span class="dolorum atque aspernatur"
  >Est molestiae sunt facilis qui rem.</span
>
<div class="voluptatem architecto at">
  Architecto rerum architecto incidunt sint.
</div>

También permitimos comentarios mágicos (ej. <!-- display: block -->) para indicar a Prettier cómo formatear elementos, dado que el display CSS puede modificarse:

<!-- input -->
<!-- display: block -->
<span class="dolorum atque aspernatur">Est molestiae sunt facilis qui rem.</span>

<!-- output -->
<!-- display: block -->
<span class="dolorum atque aspernatur">
  Est molestiae sunt facilis qui rem.
</span>

También hay una opción para la sensibilidad global a espacios en blanco en caso de que prefieras máxima seguridad o simplemente no te importen esos espacios:

--html-whitespace-sensitivity (por defecto css)

  • css - Respeta el valor predeterminado de la propiedad CSS display.

  • strict - Todos los espacios en blanco se consideran significativos.

  • ignore - Todos los espacios en blanco se consideran insignificantes.

Inferencia automática de parser​

Prettier usa el nombre del archivo para inferir qué parser utilizar. Estos son los patrones predeterminados para HTML, Vue y Angular:

  • *.html: --parser html

  • *.component.html: --parser angular

  • *.vue: --parser vue

Asegúrate de que tu nombre de archivo coincida con el parser correcto (especialmente usuarios de Angular); si no coincide, deberás especificar manualmente qué parser usar mediante el campo overrides.

Ten en cuenta que el formateo específico del framework no se activará en --parser html.

Literales de plantilla HTML en JavaScript​

Esta versión también añade soporte para la etiqueta de plantilla html (o un comentario "tag" que contenga HTML):

  • html`code`

  • /* HTML */ `code`

// input
const foo = html`<div class="voluptatem architecto at">Architecto rerum ${interpolation} architecto incidunt sint.</div>`;

// output
const foo = html`
  <div class="voluptatem architecto at">
    Architecto rerum ${interpolation} architecto incidunt sint.
  </div>
`;
Formateo de Vue​

Se admiten las siguientes estructuras de sintaxis específicas de Vue:

  • interpolación

    • {{ something }}

  • atributo

    • v-something
    • :something
    • @something
    • v-for
    • slot-scope
Formateo de Angular​

Se admiten las siguientes estructuras sintácticas específicas de Angular:

  • interpolación

    • {{ something }}

  • atributo

    • (something)
    • [something]
    • [(something)]
    • *something

  • plantilla en línea

    • @Component({ template: `<div>Hello World</div>` })

MDX​

Soporte para MDX (#4975 por @ikatyang)​

MDX es una extensión de markdown que permite usar JSX para crear documentación interactiva. ¡Ahora puedes usar Prettier para formatearlo, y formatearemos tanto las partes Markdown como JS por ti!

<!-- Input -->

import {
  colors } from
   './theme'
import     Palette from     './components/palette'

#      Colors

<Palette colors={
      colors}
  />

<!-- Output -->

import { colors } from "./theme";
import Palette from "./components/palette";

# Colors

<Palette colors={colors} />

JavaScript​

Aplanar rama else en ternarios anidados (#5039 por @suchipi, #5272 por @duailibe, #5333 por @ikatyang)​

Anteriormente, los ternarios anidados siempre se indentaban, lo que causaba niveles crecientes de sangría en ternarios profundamente anidados. Para resolver esto, aplanamos la rama else de los ternarios anidados de manera similar a cómo se formatean los bloques if..else if..else.

// Input
const example1 =
    someValue === 'a' ? 'hello world, branch a'
  : someValue === 'b' ? 'hello world, branch a && b'
  : someValue === 'c' ? 'hello world, branch a && b && c'
  : someValue === 'd' ? 'hello world, branch a && b && c && d'
  : null;

const example2 =
  someValue === 'a'
    ? someValue === 'b'
      ? someValue === 'c'
        ? 'hello world, branch a && b && c'
        : 'hello world, branch a && b && !c'
      : 'hello world, branch a && !b'
    : null;

// Output (Prettier 1.14)
const example1 =
  someValue === "a"
    ? "hello world, branch a"
    : someValue === "b"
      ? "hello world, branch a && b"
      : someValue === "c"
        ? "hello world, branch a && b && c"
        : someValue === "d"
          ? "hello world, branch a && b && c && d"
          : null;

const example2 =
  someValue === "a"
    ? someValue === "b"
      ? someValue === "c"
        ? "hello world, branch a && b && c"
        : "hello world, branch a && b && !c"
      : "hello world, branch a && !b"
    : null;

// Output (Prettier 1.15)
const example1 =
  someValue === "a"
    ? "hello world, branch a"
    : someValue === "b"
    ? "hello world, branch a && b"
    : someValue === "c"
    ? "hello world, branch a && b && c"
    : someValue === "d"
    ? "hello world, branch a && b && c && d"
    : null;

const example2 =
  someValue === "a"
    ? someValue === "b"
      ? someValue === "c"
        ? "hello world, branch a && b && c"
        : "hello world, branch a && b && !c"
      : "hello world, branch a && !b"
    : null;

Mantener decoradores en línea si se escribieron así (#5188 por @duailibe)​

Antes de Prettier 1.14, siempre colocábamos los decoradores en la misma línea que lo que decoraban.

Recibimos comentarios de algunos usuarios indicando que este formato no era ideal, así que tras considerarlo, lo cambiamos en Prettier 1.14 para que los decoradores siempre estuvieran en una línea separada de lo que decoraban.

Sin embargo, otros usuarios nos hicieron llegar que este formato no era ideal en todos los casos.

Queremos tener un formato consistente en Prettier siempre que sea posible, así que intentamos establecer una heurística para decidir cuándo poner los decoradores en la misma línea y cuándo en otra.

No obstante, tras una larga discusión en #4924, concluimos que no hay forma confiable de identificar cuáles deberían ir en línea y cuáles no, por lo que en Prettier 1.15 decidimos respetar el estilo original del usuario. Si pusieron un salto de línea entre el decorador y lo que decora, lo mantendremos. Si no lo hicieron, no lo añadiremos.

// Input
class Hello {
  @decorator inline = 'value';

  @decorator
  ownLine = 'value';

  @decorator({
    hello: 'world'
  }) multiLine = 'value';
}

// Output (Prettier 1.14)
class Hello {
  @decorator
  inline = "value";

  @decorator
  ownLine = "value";

  @decorator({
    hello: "world"
  })
  multiLine = "value";
}

// Output (Prettier 1.15)
class Hello {
  @decorator inline = "value";

  @decorator
  ownLine = "value";

  @decorator({
    hello: "world"
  })
  multiLine = "value";
}

Respetar orden original de decoradores (#5207 por @duailibe)​

Los decoradores aún no son parte del estándar oficial ECMA y [dónde deben ir los decoradores en clases exportadas] es una pregunta sin respuesta definitiva. Para ayudar a los autores de propuestas a obtener retroalimentación, Babel 7 añadió soporte para decoradores tanto antes como después de las clases exportadas. Prettier 1.15 añade soporte para ellos y respeta dónde colocas el/los decorador(es). (Una vez que el estándar se formalice, lo cambiaremos para que sea consistente sin respetar la entrada del usuario.)

// decorator before export
@decorator export class Bar {}

// decorator after export
export @decorator class Foo {}

Heurística mejorada para ruptura de objetos (#5205 por @j-f1)​

Anteriormente, Prettier rompía automáticamente los objetos en múltiples líneas si no cabían en el ancho de impresión. También mantenía los objetos en múltiples líneas si había un salto de línea dentro de ellos en el código original. Esto dificultaba colapsar un objeto ya que debías fusionarlo manualmente en una sola línea. Como los cambios manuales de formato son algo que Prettier busca eliminar, hemos cambiado el comportamiento para solo verificar un salto de línea entre el { y la primera clave:

// Input
const data = {  foo: 'bar',
  baz: 'quux'
}
/* You’d get this format by deleting the newline after the `{` */

// Output (Prettier 1.14)
const data = {
  foo: 'bar',
  baz: 'quux'
}

// Output (Prettier 1.15)
const data = { foo: 'bar', baz: 'quux' }

JSX​

Opción para usar comillas simples en JSX (#4798 por @smirea)​

Tras una gran demanda de la comunidad, Prettier 1.15 añade una opción para imprimir comillas simples en JSX: --jsx-single-quote (o jsxSingleQuote en la configuración/API).

// with --jsx-single-quote
<div class='hello'>world</div>

// without --jsx-single-quote
<div class="hello">world</div>

Dividir correctamente el texto JSX (#5006 por @yuliaHope)​

Prettier 1.14 introdujo accidentalmente saltos de línea problemáticos en JSX. Estos casos ahora están corregidos.

// Input
<div>
  Sales tax estimated using a rate of {salesTax * 100}%.
</div>;
<BasicText light>(avg. {value}/5)</BasicText>;
<Link to={orgURL(this.props.org.name)}>
  Go to {this.props.org.name}'s profile
</Link>;

// Output (Prettier 1.14)
<div>
  Sales tax estimated using a rate of {salesTax * 100}
  %.
</div>;
<BasicText light>
  (avg. {value}
  /5)
</BasicText>;
<Link to={orgURL(this.props.org.name)}>
  Go to {this.props.org.name}
  's profile
</Link>;

// Output (Prettier 1.15)
<div>Sales tax estimated using a rate of {salesTax * 100}%.</div>;
<BasicText light>(avg. {value}/5)</BasicText>;
<Link to={orgURL(this.props.org.name)}>
  Go to {this.props.org.name}'s profile
</Link>;

Flow​

Soporte para tipos inexactos (#5304 por @jbrown215, #5356 por @existentialism)​

El equipo de Flow planea tratar todos los tipos de objeto como exactos por defecto en el futuro, por lo que introdujeron una nueva sintaxis para indicar si un tipo de objeto es inexacto. Esta sintaxis ahora es compatible en Prettier 1.15.

type T = {
  a: number,
  ...
}

No romper comentarios de typecast de Flow (#5280, #5290 por @swac)​

Anteriormente, los paréntesis que rodeaban comentarios de typecast de Flow a veces se eliminaban, lo que rompía la sintaxis de comentarios de Flow. Este problema está corregido en Prettier 1.15.

// Input
(obj /*: Class */).property

// Output (Prettier 1.14)
obj /*: Class */.property;

// Output (Prettier 1.15)
(obj /*: Class */).property;

Markdown​

Conservar sintaxis matemática (#5050, #5220 por @ikatyang)​

Anteriormente, algunas estructuras sintácticas de remark-math se alteraban al tratarlas como texto normal. Ahora se conservan en Prettier 1.15 para usar sintaxis matemática con seguridad.

$inline-math$

$$
block-math
$$

Otros cambios​

API/CLI​

Inferir analizador mediante shebang cuando no hay extensión en el nombre del archivo (#5149 por @haggholm)​

Anteriormente, usábamos el nombre y extensión del archivo para inferir el analizador, pero los scripts CLI frecuentemente carecen de extensión, obligando a especificar manualmente el analizador. En Prettier 1.15, al formatear archivos sin extensión, examinamos la primera línea del archivo, y si contiene un shebang, lo usamos para inferir el analizador.

# Input
$ cat bin/example
#!/usr/bin/env node
  require ( "../src/cli" ) . run ( )

$ prettier bin/example

# Output (Prettier 1.14)
[error] No parser could be inferred for file: bin/example

# Output (Prettier 1.15)
#!/usr/bin/env node
require("../src/cli").run();

Añadir nuevo comando trim para eliminar espacios en blanco en la línea actual (#4772 por @warrenseine)​

Anteriormente en la API de plugins, no existía un método para eliminar la indentación de la línea actual. Aunque existían soluciones alternativas, ninguna era totalmente fiable, por lo que introdujimos un nuevo comando trim para eliminar espacios de forma confiable.

Mensajes de validación con color (#5020, #5057 por @ikatyang)​

Anteriormente, los mensajes de error de validación carecían de color, dificultando identificar qué opción tenía un valor inválido y cuáles eran los valores permitidos. En Prettier 1.15, esta información será visible de un vistazo.

# Input
$ prettier filename.js --trailing-comma wow

# Output (Prettier 1.14)
[error] Invalid ``--trailing-comma`` value. Expected "all", "es5" or "none", but received `"wow"`.

# Output (Prettier 1.15)
[error] Invalid --trailing-comma value. Expected "all", "es5" or "none", but received "wow".

Permitir preprocesamiento del AST en la impresora (#5041 por @ikatyang)​

A veces necesitamos transformar el AST para facilitar su impresión. Anteriormente, esto se hacía en el parser, pero este enfoque exponía detalles internos a usuarios externos que podrían intentar construir un parser personalizado, lo cual no es ideal. En Prettier 1.15, ahora puedes usar printer.preprocess para preprocesar el AST sin exponer detalles internos de la API.

interface Printer {
  preprocess(ast: AST, options: object): AST;
}

Mejor mensaje de error para formatos de configuración no soportados (#4969 by @ikatyang)​

Anteriormente, cargar un archivo de configuración con formato no soportado mostraba un mensaje de error que parecía un bug en Prettier. En la versión 1.15 hemos mejorado este mensaje.

# Input
$ prettier filename.js --config .prettierrc.wow

# Output (Prettier 1.14)
[error] Invalid configuration file: Cannot read property 'sync' of undefined

# Output (Prettier 1.15)
[error] Invalid configuration file: No sync loader specified for extension ".wow"

Nueva opción para forzar tipos de fin de línea (#5327 by @kachkaev)​

Anteriormente, Prettier siempre respetaba los fines de línea originales, lo cual es correcto en la mayoría de casos. Pero cuando varias personas colaboran en un proyecto desde diferentes sistemas operativos, es fácil terminar con mezclas de fines de línea en el repositorio central de git, generando grandes diffs. Prettier 1.15 añade la opción --end-of-line <auto|lf|crlf|cr> para ayudarte a gestionar estos problemas.

JavaScript​

Tratar comentarios de una estrella como JSDoc (#5206 by @j-f1, #5330 by @lydell)​

Prettier ahora indentará correctamente comentarios estilo JSDoc con solo un * en la primera línea (/* vs /**) cuando cambia la indentación del comentario:

// Input
if (true) {
    /*
     * Oh no
     */
}

// Output (Prettier 1.14)
if (true) {
  /*
   	 * Oh no
 	   */
}

// Output (Prettier 1.15)
if (true) {
  /*
 	 * Oh no
 	 */
}

Paréntesis correctos para mezcla de exponenciación/módulo (#5243 by @bakkot)​

Anteriormente se eliminaban incorrectamente paréntesis en mezclas de exponenciación/módulo, pero esto se corrigió en Prettier 1.15.

// Input
const val = (n % 10) ** 2

// Output (Prettier 1.14)
const val = n % 10 ** 2;

// Output (Prettier 1.15)
const val = (n % 10) ** 2;

Imprimir correctamente comentarios en try..finally (#5252 by @aquibm)​

En versiones anteriores, algunos comentarios en sentencias try-finally se imprimían en orden incorrecto. Ahora Prettier los imprime correctamente.

// Input
// comment 1
try {
    // comment 2
}
// comment 3
finally // comment 4
{
    // comment 5
}

// Output (Prettier 1.14)
// comment 1
try {
  // comment 2
} finally { // comment 4
  // comment 3
  // comment 5
}

// Output (Prettier 1.15)
// comment 1
try {
  // comment 2
} finally {
  // comment 3
  // comment 4
  // comment 5
}

Ubicar comentarios en cláusulas catch correctamente (#5202 by @duailibe)​

Los comentarios en cláusulas catch ahora se imprimen en su propia línea, igual que en otras cláusulas.

// Input
try {} catch (
  // comment
  e
) {}

// Output (Prettier 1.14)
try {
} catch (// comment
e) {}

// Output (Prettier 1.15)
try {
} catch (
  // comment
  e
) {}

Incluir inline el argumento si es una función flecha con expresión condicional como cuerpo (#5209 by @duailibe)​

No es necesario añadir un nivel extra de indentación para argumentos de llamadas de función que sean funciones flecha con expresiones condicionales como cuerpo. En Prettier 1.15 ahora los incluimos inline.

// Input
x.then(() => a ?
  veryVerVeryveryVerVeryveryVerVeryveryVerVeryLong:
  veryVerVeryveryVerVeryveryVerVeryveryVerVeryLong
);

// Output (Prettier 1.14)
x.then(
  () =>
    a
      ? veryVerVeryveryVerVeryveryVerVeryveryVerVeryLong
      : veryVerVeryveryVerVeryveryVerVeryveryVerVeryLong
);

// Output (Prettier 1.15)
x.then(() =>
  a
    ? veryVerVeryveryVerVeryveryVerVeryveryVerVeryLong
    : veryVerVeryveryVerVeryveryVerVeryveryVerVeryLong
);

Corregir indentación inesperada en declaradores de variables causada por comentarios (#5190 by @duailibe)​

En versiones anteriores, los comentarios en declaraciones de variables causaban que los declaradores se imprimieran sin indentación. Esto se corrigió en Prettier 1.15.

// Input
const // Comment
	a = 1;

// Output (Prettier 1.14)
const // Comment
a = 1;

// Output (Prettier 1.15)
const // Comment
  a = 1;

No eliminar paréntesis para ternarios en expresiones de miembros opcionales (#5179 by @existentialism)​

Prettier 1.14 eliminaba incorrectamente paréntesis alrededor de operadores ternarios dentro de expresiones de miembros opcionales (?.). Estos casos ahora se imprimen correctamente en la versión 1.15.

// Input
(a ? b : c)?.d;

// Output (Prettier 1.14)
a ? b : c?.d;

// Output (Prettier 1.15)
(a ? b : c)?.d;

Escapar ${ y backticks en etiquetas GraphQL (#5137 by @lydell)​

Anteriormente, cadenas tipo interpolación se escapaban incorrectamente en GraphQL embebido, haciendo que JavaScript las interpretara como interpolaciones. En Prettier 1.15 se escapan correctamente.

// Input
const schema = gql`
type Project {
    "Pattern: \`\${project}\`"
    pattern: String
}
`;

// Output (Prettier 1.14)
const schema = gql`
  type Project {
    "Pattern: \`${project}\`"
    pattern: String
  }
`;

// Output (Prettier 1.15)
const schema = gql`
  type Project {
    "Pattern: \`\${project}\`"
    pattern: String
  }
`;

No eliminar comillas en claves si no son compatibles con ES5 (#5157 by @koba04)​

Prettier eliminaba comillas en claves cuando no eran necesarias en ES2015, lo que generaba incompatibilidad con ES5. En la versión 1.15 solo las elimina si no son necesarias en ES5.

// Input
var obj = {
  "𐊧": 'ok',
  𐊧: 'ok'
};

// Output (Prettier 1.14)
var obj = {
  𐊧: "ok",
  𐊧: "ok"
};

// Output (Prettier 1.15)
var obj = {
 "𐊧": "ok",
  𐊧: "ok"
};

No ajustar argumentos si el segundo argumento en una función es un ternario (#5151 por @onurtemizkan)​

Tenemos casos especiales que ajustaban los argumentos de llamadas a funciones cuando el primero era una función y el segundo no era una expresión compleja, pero considerábamos que los ternarios no eran expresiones complejas. En realidad pueden ser complejos, así que lo hemos cambiado en Prettier 1.15.

// Input
func(
  () => { thing(); },
  something(longArgumentName, anotherLongArgumentName) ? someOtherThing() : somethingElse(true, 0)
);

// Output (Prettier 1.14)
func(() => {
  thing();
}, something(longArgumentName, anotherLongArgumentName) ? someOtherThing() : somethingElse(true, 0));

// Output (Prettier 1.15)
func(
  () => {
    thing();
  },
  something(longArgumentName, anotherLongArgumentName)
    ? someOtherThing()
    : somethingElse(true, 0)
);

Añadir soporte para timeouts numéricos en funciones de test (#5085 por @j-f1)​

Esto preserva el formato especial de Prettier para funciones de prueba cuando se pasa un timeout (número) como tercer parámetro:

// Input
it('Handles at least 10k untracked files without failing', async () => {
  hello()
}, 25000)

// Output (Prettier 1.14)
it(
  "Handles at least 10k untracked files without failing",
  async () => {
    hello();
  },
  25000
);

// Output (Prettier 1.15)
it('Handles at least 10k untracked files without failing', async () => {
  hello()
}, 25000)

Formatear llamadas tipo beforeEach como llamadas de función regulares (#5011 por @ericsakmar)​

Formatear llamadas tipo beforeEach como llamadas normales (#5011 por @ericsakmar)​

// Input
beforeEach(done =>
  startService()
    .pipe(tap(service => (instance = service)))
    .subscribe(() => done()),
);

// Output (Prettier 1.14)
beforeEach(done =>
  startService()
    .pipe(tap(service => (instance = service)))
    .subscribe(() => done()));

// Output (Prettier 1.15)
beforeEach(done =>
  startService()
    .pipe(tap(service => (instance = service)))
    .subscribe(() => done())
);

Imprimir el comentario inicial del operador de tubería en su propia línea (#5015 por @flxwu)​

Imprimir comentarios iniciales del operador pipeline en su propia línea (#5015 por @flxwu)​

// Input
function pipeline() {
	0
	// Comment
	|> x
}

// Output (Prettier 1.14)
function pipeline() {
  0
    |> // Comment
    x;
}

// Output (Prettier 1.15)
function pipeline() {
  0 |>
    // Comment
    x;
}

Conservar comentarios colgantes en expresiones new (#5017 por @flxwu)​

Preservar comentarios sueltos en expresiones new (#5017 por @flxwu)​

// Input
new Thing(/* comment */)

// Output (Prettier 1.14)
new Thing /* comment */();

// Output (Prettier 1.15)
new Thing(/* comment */);

Eliminar la protección ASI redundante para la expresión bind (#4970 por @TitanSnow)​

Los puntos y coma innecesarios para las expresiones bind se eliminan con --no-semi en Prettier 1.15.

// Input
a::b.c

// Output (Prettier 1.14)
;a::b.c

// Output (Prettier 1.15)
a::b.c

No eliminar los paréntesis necesarios en la expresión bind (#4964 por @TitanSnow)​

No eliminar paréntesis necesarios en expresiones bind (#4964 por @TitanSnow)​

// Input
a::(b.c());

// Output (Prettier 1.14)
a::b.c();

// Output (Prettier 1.15)
a::(b.c());

Flow​

Corregir sangría para ternarios en llamadas a funciones (#4368 por @malcolmsgroves)​

// Input
fn(
  bifornCringerMoshedPerplexSawder,
  askTrovenaBeenaDependsRowans,
  glimseGlyphsHazardNoopsTieTie === averredBathersBoxroomBuggyNurl &&
    anodyneCondosMalateOverateRetinol // <--
    ? annularCooeedSplicesWalksWayWay
    : kochabCooieGameOnOboleUnweave
);

// Output (Prettier 1.14)
fn(
  bifornCringerMoshedPerplexSawder,
  askTrovenaBeenaDependsRowans,
  glimseGlyphsHazardNoopsTieTie === averredBathersBoxroomBuggyNurl &&
  anodyneCondosMalateOverateRetinol // <--
    ? annularCooeedSplicesWalksWayWay
    : kochabCooieGameOnOboleUnweave
);

// Output (Prettier 1.15)
fn(
  bifornCringerMoshedPerplexSawder,
  askTrovenaBeenaDependsRowans,
  glimseGlyphsHazardNoopsTieTie === averredBathersBoxroomBuggyNurl &&
    anodyneCondosMalateOverateRetinol // <--
    ? annularCooeedSplicesWalksWayWay
    : kochabCooieGameOnOboleUnweave
);

No mueva los comentarios en imports (#5016 por @ericsakmar)​

No mover comentarios en imports ni en la salida del import (#5016 por @ericsakmar)​

// Input
import x, {
  // comment
  y
} from 'z';


// Output (Prettier 1.14)
import x, { y } from "z";
// comment

// Output (Prettier 1.15)
import x, {
  // comment
  y
} from "z";

Corrige comentario inestable en while (#5251 by @jaideng123)​

Corregir comentarios inestables en while (#5251 por @jaideng123)​

// Input
while(
    true
    // Comment
) {}

// First Output (Prettier 1.14)
while (true) // Comment
{}

// Second Output (Prettier 1.14)
while (
  true // Comment
) {}

// First & Second Output (Prettier 1.15)
while (
  true
  // Comment
) {}

Impresión estable de comentarios entre la declaración de función y su cuerpo (#5250 by @jaideng123)​

Imprimir establemente comentarios entre declaración de función y su cuerpo (#5250 por @jaideng123)​

// Input
function foo() // this is a function
{
  return 42
}

// First Output (Prettier 1.14)
function foo() { // this is a function
  return 42;
}

// Second Output (Prettier 1.14)
function foo() {
  // this is a function
  return 42;
}

// First & Second Output (Prettier 1.15)
function foo() {
  // this is a function
  return 42;
}

JSX​

No romper cadenas de expresiones lógicas en JSX (#5092 por @duailibe)​

Ahora se evitan sangrías innecesarias en cadenas de expresiones lógicas dentro de JSX.

// Input
const TestComponent = () => {
  return (
    <>
      {cats && memes && (
        <Foo bar><Trololol /></Foo>
      )}
    </>
  );
}

// Output (Prettier 1.14)
const TestComponent = () => {
  return (
    <>
      {cats &&
        memes && (
          <Foo bar>
            <Trololol />
          </Foo>
        )}
    </>
  );
};

// Output (Prettier 1.15)
const TestComponent = () => {
  return (
    <>
      {cats && memes && (
        <Foo bar>
          <Trololol />
        </Foo>
      )}
    </>
  );
};

No convertir espacios de no separación en espacios regulares (#5165 por @vjeux, #5334 por @ikatyang)​

Anteriormente, los espacios de no separación se trataban como espacios regulares, lo que causaba su reemplazo. Este problema se ha solucionado en Prettier 1.15.

(· representa un espacio de no separación)

// Input
function OhMyWhitespace() {
  return (
    <Dialog>
      <p>
        Supprimer l’objectif «·{goal.name}·»·?
      </p>
    </Dialog>
  )
}

// Output (Prettier 1.14)
function OhMyWhitespace() {
  return (
    <Dialog>
      <p>
        Supprimer l’objectif «
        {goal.name}
        ·»·?
      </p>
    </Dialog>
  );
}

// Output (Prettier 1.15)
function OhMyWhitespace() {
  return (
    <Dialog>
      <p>Supprimer l’objectif «·{goal.name}·»·?</p>
    </Dialog>
  );
}

No dividir la etiqueta de apertura jsx simple (#5078 by @duailibe)​

No romper etiquetas JSX de apertura simples (#5078 por @duailibe)​

// Input
function HelloWorld() {
  const listItemText = (
    <ListItemText
      primary={
        <PrimaryText>{`Two Factor Authentication is ${enabledText}`}</PrimaryText>
      }
    />
  );
}

// Output (Prettier 1.14)
function HelloWorld() {
  const listItemText = (
    <ListItemText
      primary={
        <PrimaryText
        >{`Two Factor Authentication is ${enabledText}`}</PrimaryText>
      }
    />
  );
}

// Output (Prettier 1.15)
function HelloWorld() {
  const listItemText = (
    <ListItemText
      primary={
        <PrimaryText>{`Two Factor Authentication is ${enabledText}`}</PrimaryText>
      }
    />
  );
}

Las etiquetas JSX de apertura simples ya no se dividen en múltiples líneas.

// Input
<div className="search-filter-chips">
    {scopes.filter(scope => scope.value !== "").map((scope, i) => (
        <FilterChip
            query={this.props.query}
            onFilterChosen={this.onSearchScopeClicked}
        />
    ))}
</div>;

// Output (Prettier 1.14)
<div className="search-filter-chips">
  {scopes.filter(scope => scope.value !== "").map((scope, i) => (
    <FilterChip
      query={this.props.query}
      onFilterChosen={this.onSearchScopeClicked}
    />
  ))}
</div>;

// Output (Prettier 1.15)
<div className="search-filter-chips">
  {scopes
    .filter(scope => scope.value !== "")
    .map((scope, i) => (
      <FilterChip
        query={this.props.query}
        onFilterChosen={this.onSearchScopeClicked}
      />
    ))}
</div>;

Flow​

Generics en línea con un solo identificador (#5066 por @duailibe)​

Los genéricos con un solo identificador ahora siempre se ponen en línea.

// Input
const longVariableName: Array<number> = this.foo.bar.baz.collider.body.vertices.reduce();

// Output (Prettier 1.14)
const longVariableName: Array<
  number
> = this.foo.bar.baz.collider.body.vertices.reduce();

// Output (Prettier 1.15)
const longVariableName: Array<number> = this.foo.bar.baz.collider.body.vertices.reduce();

No siempre poner en línea las clases en extends (#5244 por @aquibm)​

Las clases en extends ahora se dividen correctamente en múltiples líneas.

// Input
declare interface ExtendsMany extends Interface1, Interface2, Interface3, Interface4, Interface5, Interface6, Interface7 {
  x: string;
}

// Output (Prettier 1.14)
declare interface ExtendsMany
  extends Interface1, Interface2, Interface3, Interface4, Interface5, Interface6, Interface7 {
  x: string;
}

// Output (Prettier 1.15)
declare interface ExtendsMany
  extends Interface1,
    Interface2,
    Interface3,
    Interface4,
    Interface5,
    Interface6,
    Interface7 {
  x: string;
}

No agregar paréntesis innecesarios para funciones asíncronas en export default (#5303 por @jbrown215)​

Ahora se eliminan los paréntesis innecesarios alrededor de export default async function. Este error solo ocurría al usar el analizador flow.

// Input
export default async function foo() {};

// Output (Prettier 1.14)
export default (async function foo() {});

// Output (Prettier 1.15)
export default async function foo() {}

TypeScript​

Agregar protección ASI para aserciones no nulas (#5262 por @duailibe)​

Los punto y coma necesarios para aserciones no nulas no se eliminarán en modo --no-semi.

// Input
const el = ReactDOM.findDOMNode(ref)
;(el as HTMLElement)!.style.cursor = 'pointer'

// Output (Prettier 1.14)
const el = ReactDOM.findDOMNode(ref)
(el as HTMLElement)!.style.cursor = "pointer"

// Output (Prettier 1.15)
const el = ReactDOM.findDOMNode(ref)
;(el as HTMLElement)!.style.cursor = "pointer"

No agregar punto y coma extra para la firma de métodos cuando se usa prettier-ignore (#5160 por @onurtemizkan)​

El punto y coma extra para la firma de métodos se eliminó en Prettier 1.15.

// Input
interface SharedWorkerGlobalScope extends WorkerGlobalScope {
    // prettier-ignore
    addEventListener(): void;
    addEventListener(type: string): void;
}

// Output (Prettier 1.14)
interface SharedWorkerGlobalScope extends WorkerGlobalScope {
  // prettier-ignore
  addEventListener(): void;;
  addEventListener(type: string): void;
}

// Output (Prettier 1.15)
interface SharedWorkerGlobalScope extends WorkerGlobalScope {
  // prettier-ignore
  addEventListener(): void;
  addEventListener(type: string): void;
}

No imprimir paréntesis inválidos para desestructuración con valor predeterminado (#5096 por @ikatyang)​

Anteriormente, Prettier imprimía paréntesis inválidos para desestructuración con valor predeterminado; hemos solucionado este problema en Prettier 1.15.

// Input
({ prop: toAssign = "default" } = { prop: "propval" });

// Output (Prettier 1.14)
({ prop: (toAssign = "default") } = { prop: "propval" });

// Output (Prettier 1.15)
({ prop: toAssign = "default" } = { prop: "propval" });

No imprimir punto y coma para propiedades de clase con modificadores en modo --no-semi (#5083 por @ikatyang)​

En Prettier 1.14, se agregaban punto y coma al final de una propiedad de clase cuando había modificadores en la siguiente propiedad; sin embargo, estos punto y coma no eran necesarios. Los punto y coma innecesarios se eliminaron en Prettier 1.15.

// Input
class Reader {
  private [kBuffer]: Buffer
  private [kOffset]: number
}

// Output (1.14)
class Reader {
  private [kBuffer]: Buffer;
  private [kOffset]: number
}

// Output (1.15)
class Reader {
  private [kBuffer]: Buffer
  private [kOffset]: number
}

No eliminar paréntesis para nodos complejos en extends de ClassExpression (#5074 por @ikatyang)​

Anteriormente, los paréntesis para nodos complejos en extends de las expresiones de clase se eliminaban incorrectamente, produciendo código inválido. Este problema se solucionó en Prettier 1.15.

// Input
let Subclass2 = class extends (Superclass as AssertedSuperclass) {};

// Output (Prettier 1.14)
let Subclass2 = class extends Superclass as AssertedSuperclass {};

// Output (Prettier 1.15)
let Subclass2 = class extends (Superclass as AssertedSuperclass) {};

No eliminar paréntesis necesarios para TSOptionalType (#5056 por @ikatyang)​

Anteriormente, los paréntesis necesarios para tipos opcionales en tuplas se eliminaban incorrectamente, produciendo código inválido. Este problema se solucionó en Prettier 1.15.

// Input
type T = [("a" | "b")?];

// Output (Prettier 1.14)
type T = ["a" | "b"?];

// Output (Prettier 1.15)
type T = [("a" | "b")?];

CSS​

No imprimir salida incorrecta si existen tanto front matter como /* prettier-ignore */ (#5103 por @ikatyang)​

En Prettier 1.14, la información de ubicación en el AST se desplazaba incorrectamente debido a cómo extraemos los front matters del código fuente, lo que hacía que /* prettier-ignore */ produjera salida inválida. Hemos solucionado este problema en Prettier 1.15.

/* Input */
---
hello: world
---

/* prettier-ignore */
.foo {}

/* Output (Prettier 1.14) */
---
hello: world
---

/* prettier-ignore */
 pretti

/* Output (Prettier 1.15) */
---
hello: world
---

/* prettier-ignore */
.foo {}

Conservar saltos de línea en plantillas CSS-in-JS (#5240 por @onurtemizkan)​

Las interpolaciones en plantillas CSS-in-JS pueden ser cualquier cosa, así que conservamos los saltos de línea para ellas en Prettier 1.15.

// Input
const foo = styled.div`
  ${secondary}
  flex: 0 0 auto;
`;

// Output (Prettier 1.14)
const foo = styled.div`
  ${secondary} flex: 0 0 auto;
`;

// Output (Prettier 1.15)
const foo = styled.div`
  ${secondary}
  flex: 0 0 auto;
`;

Markdown​

Se permiten espacios finales para los delimitadores de front matter (#5107 por @ikatyang)​

Anteriormente, solo detectábamos front matters que no usaban espacios finales en sus delimitadores, lo que provocaba que los saltos temáticos (es decir, ---) se reconocieran incorrectamente como el final del front matter. Hemos solucionado este problema permitiendo espacios finales en los delimitadores de front matter en Prettier 1.15, que es también la forma en que GitHub procesa los front matters.

(· representa un espacio en blanco)

<!-- Input -->
---
Title: Title
---···

__strong__ **strong**

---

<!-- Output (Prettier 1.14) -->
---
Title: Title
---···
__strong__ **strong**
---

<!-- Output (Prettier 1.15) -->
---
Title: Title
---···

**strong** **strong**

---

No agregar espacios entre latín y hangul (#5040 por @ikatyang)​

Anteriormente, Prettier siempre insertaba espacios entre caracteres latinos y CJK para mejorar la legibilidad. Sin embargo, según los comentarios recibidos, el coreano utiliza espacios convencionales y esta inserción causaba problemas. Por ello, en la versión 1.15 desactivamos este comportamiento para el hangul. El formato para chino y japonés no cambia.

<!-- Input -->
예문Latin예문Latin 예문Latin예문 Latin예문Latin 예문 Latin 예문

<!-- Output (Prettier 1.14) -->
예문 Latin 예문 Latin 예문 Latin 예문 Latin 예문 Latin 예문 Latin 예문

<!-- Output (Prettier 1.15) -->
예문Latin예문Latin 예문Latin예문 Latin예문Latin 예문 Latin 예문

Preservar saltos de línea iniciales y finales en bloques de código delimitados (#5038 por @ikatyang)​

En Prettier 1.14 se eliminaban los saltos de línea iniciales y finales en bloques de código delimitados, lo que causaba errores en otros plugins (como php). En la versión 1.15 estos saltos de línea se preservan correctamente.

<!-- Input -->
```

hello

```

<!-- Output (Prettier 1.14) -->
```
hello
```

<!-- Output (Prettier 1.15) -->
```

hello

```

Definiciones de nota al pie en línea cuando hay un párrafo de una sola línea (#5025 por @ikatyang)​

Antes, cualquier contenido que excediera el ancho de impresión en definiciones de notas al pie se dividía en múltiples líneas. Sin embargo, dividir un párrafo de una sola línea no mejoraba la legibilidad, por lo que en Prettier 1.15 siempre lo mantenemos en una sola línea.

<!-- Input -->
[^1]: In eos repellat fugit dolor veritatis doloremque nobis. Provident ut est illo.

<!-- Output (Prettier 1.14) -->
[^1]:

  In eos repellat fugit dolor veritatis doloremque nobis. Provident ut est illo.

<!-- Output (Prettier 1.15) -->
[^1]: In eos repellat fugit dolor veritatis doloremque nobis. Provident ut est illo.

Formatear correctamente listas antes de saltos de línea con solo espacios en blanco (#5024 por @ikatyang)​

En Prettier 1.14, las listas precedidas por saltos de línea con solo espacios en blanco se identificaban erróneamente como listas sueltas. Esto obligaba a los usuarios a formatear su código dos veces para estabilizarlo, produciendo luego un resultado incorrecto. Este error se corrigió en la versión 1.15.

// Input
if (condition) {
  md`
- 123
  - 456
`;
}

// First Output (Prettier 1.14)
if (condition) {
  md`
- 123
  - 456
  `;
}

// Second Output (Prettier 1.14)
if (condition) {
  md`
- 123

  - 456
  `;
}

// First & Second Output (Prettier 1.15)
if (true) {
  md`
- 123
  - 456
  `;
}

YAML​

Escapar comillas correctamente (#5236 por @ikatyang)​

Anteriormente, las cadenas con comillas escapadas en comillas dobles generaban salidas inválidas. En Prettier 1.15 se escapan correctamente.

# Input
"'a\"b"

# Output (Prettier 1.14)
''a"b'

# Output (Prettier 1.15)
'''a"b'

Preservar comentarios finales en documentos y cabeceras de documento (#5027 por @ikatyang)​

En Prettier 1.14, algunos comentarios finales en documentos y cabeceras podían moverse de posición. En la versión 1.15 siempre se preservan en su ubicación original.

# Input
--- # hello
... # world

# Output (Prettier 1.14)
# hello
# world

# Output (Prettier 1.15)
--- # hello
... # world

Evitar errores en elementos de mapeo de flujo con valores largos (#5027 por @ikatyang)​

Anteriormente, los valores largos en mapeos de flujo se identificaban erróneamente como claves, lo que producía errores de sintaxis ya que las claves implícitas con más de 1024 caracteres no están permitidas. Este problema se solucionó en Prettier 1.15.

(long representa un texto extenso de más de 1024 caracteres)

# Input
{x: long}

# Output (Prettier 1.14)
SyntaxError: The "undefine...ndefined" key is too long

# Output (Prettier 1.15)
{
  x: long
}

Preferir claves implícitas para valores de mapeo vacíos (#4972 por @ikatyang)​

Anteriormente, los elementos de mapeo con valores vacíos siempre usaban [claves explícitas], lo que resultaba poco común y confuso. En Prettier 1.15 siempre usamos claves implícitas en estos casos.

# Input
a:
  b:

# Output (Prettier 1.14)
a:
  ? b

# Output (Prettier 1.15)
a:
  b:

¡Gracias! ❤️​

Agradecemos a todos los que contribuyeron a esta versión, así como a quienes reportaron problemas y nos dieron feedback. Prettier es un proyecto impulsado por la comunidad y solo puede continuar gracias a personas como ustedes. ¡Muchas gracias!

¡Agradecimiento especial a @j-f1, @suchipi y @existentialism por revisar esta publicación de blog!