Prettier 1.18: Muchas correcciones y OpenCollective

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 no incluye nuevas funciones llamativas, pero contiene numerosas correcciones para JavaScript, especialmente JSX y literales de plantilla, TypeScript y Markdown.

También es una buena oportunidad para recordar que ¡Prettier ahora acepta donaciones! Si disfrutas usando Prettier y quieres apoyar nuestro trabajo, visita nuestro OpenCollective.

Destacados

JavaScript

Evitar ruptura en literales de plantilla simples (#5979 por @jwbay)

Esta es una de las partes de Prettier que recibe muchas solicitudes de cambio: romper expresiones simples dentro de literales de plantilla. Anteriormente Prettier dividía las expresiones en múltiples líneas si todo el literal superaba el ancho de impresión. Ahora evitaremos la ruptura si la expresión es simple.

Esto mejora lo que teníamos antes, pero aún queda trabajo por hacer en esta área.

// Input
console.log(chalk.white(`Covered Lines below threshold: ${coverageSettings.lines}%. Actual: ${coverageSummary.total.lines.pct}%`))

// Output (Prettier stable)
console.log(
  chalk.white(
    `Covered Lines below threshold: ${coverageSettings.lines}%. Actual: ${
      coverageSummary.total.lines.pct
    }%`
  )
);

// Output (Prettier master)
console.log(
  chalk.white(
    `Covered Lines below threshold: ${coverageSettings.lines}%. Actual: ${coverageSummary.total.lines.pct}%`
  )
);

Dejar de convertir elementos JSX vacíos a elementos autocerrables (#6127 por @duailibe)

Prettier siempre ha convertido elementos JSX vacíos (<div></div>) en elementos autocerrables (<div />) porque son equivalentes.

Hemos recibido comentarios de que durante el desarrollo, uno podría querer escribir las etiquetas de apertura y cierre para luego añadir los elementos hijos, pero Prettier los convertía a elementos autocerrables, obligando al desarrollador a revertirlos manualmente. Esto ha cambiado en esta versión.

// Input
function Foo() {
  return <div></div>;
}

// Output (Prettier stable)
function Foo() {
  return <div />;
}

// Output (Prettier master)
function Foo() {
  return <div></div>;
}

Otros cambios

JavaScript

Corregir typecasts de Closure Compiler (#5947 por @jridgewell)

Si un paréntesis de cierre sigue después de un typecast en una expresión interna, el typecast envolvía todo hasta ese paréntesis siguiente.

// Input
test(/** @type {!Array} */(arrOrString).length);
test(/** @type {!Array} */((arrOrString)).length + 1);
// Output (Prettier stable)
test(/** @type {!Array} */ (arrOrString.length));
test(/** @type {!Array} */ (arrOrString.length + 1));
// Output (Prettier master)
test(/** @type {!Array} */ (arrOrString).length);
test(/** @type {!Array} */ (arrOrString).length + 1);

Corregir typecasts de Closure sin espacios (#6116 por @jridgewell)

Anteriormente se requería un espacio entre @type y la apertura { de un typecast de Closure, o de lo contrario se eliminaban los paréntesis envolventes. El propio Closure no requiere este espacio.

// Input
const v = /** @type{string} */(value);

// Output (Prettier stable)
const v = /** @type{string} */ value;

// Output (prettier master)
const v = /** @type{string} */ (value);

Evitar añadir comillas al usar --quote-props=consistent cuando los objetos tenían números o expresiones computadas como claves (#6119 y #6138 por @duailibe)

Anteriormente Prettier añadía comillas innecesarias a claves de objetos, o propiedades y métodos de clases, si había al menos una clave computada con expresión "compleja" (ej. expresión de miembro) o un literal numérico.

// Input
const obj = {
  foo: "",
  [foo.bar]: "",
};

const other = {
  foo: "",
  1: ""
};

// Output (Prettier stable)
const obj = {
  "foo": "",
  [foo.bar]: "",
};

const other = {
  "foo": "",
  1: ""
};

// Output (Prettier master)
const obj = {
  foo: "",
  [foo.bar]: "",
};

const other = {
  foo: "",
  1: ""
};

Añadir paréntesis en elementos de propagación JSX con expresiones lógicas (#6130 por @duailibe)

Anteriormente Prettier no añadía paréntesis en elementos de propagación JSX porque no son necesarios, pero para mantener coherencia con el operador de propagación en objetos y arreglos, ahora también los añadiremos en JSX.

// Input
<Component {...(props || {})} />;

// Output (Prettier stable)
<Component {...props || {}} />;

// Output (Prettier master)
<Component {...(props || {})} />;

Manejar correctamente comentarios en expresiones de función flecha vacías (#6086 por @evilebottnawi)

// Input
const fn = (/*event, data*/) => doSomething(anything);

// Output (Prettier stable)
const fn = () => /*event, data*/ doSomething(anything);

// Output (Prettier master)
const fn = (/*event, data*/) => doSomething(anything);

Evitar compactar expresiones secuenciales en propiedades de objetos (#6088 por @evilebottnawi)

// Input
const a = {
  someKey:
    (longLongLongLongLongLongLongLongLongLongLongLongLongLongName, shortName)
};

// Output (Prettier stable)
const a = {
  someKey: (longLongLongLongLongLongLongLongLongLongLongLongLongLongName,
  shortName)
};

// Output (Prettier master)
const a = {
  someKey:
    (longLongLongLongLongLongLongLongLongLongLongLongLongLongName, shortName)
};

Añadir soporte para estilos externos de styled-jsx (#6089 por @hongrich)

Añadir soporte para 2 etiquetas de estilos externos en styled-jsx/css: css.global y css.resolve. https://github.com/zeit/styled-jsx/#external-css-and-styles-outside-of-the-component

La etiqueta de plantilla css ya está soportada por Prettier.

// Input
const styles = css.resolve`
.box {background:black;
}`;

// Output (Prettier stable)
const styles = css.resolve`
.box {background:black;
}`;

// Output (prettier master)
const styles = css.resolve`
  .box {
    background: black;
  }
`;

Conservar paréntesis alrededor de funciones y clases en declaraciones export default (#6133 por @duailibe)

Prettier estaba eliminando paréntesis de algunas expresiones en export default, pero cuando son expresiones complejas que comienzan con function o class, los paréntesis son requeridos.

A continuación se muestran algunos ejemplos prácticos, incluyendo uno que afecta a TypeScript.

// Input
export default (function log() {}).toString();
export default (function log() {} as typeof console.log);

// Output (Prettier stable)
export default function log() {}.toString();
export default function log() {} as typeof console.log; // syntax error

// Output (Prettier master)
export default (function log() {}).toString();
export default (function log() {} as typeof console.log);

Solución de errores de paréntesis en casos extremos con llamadas y new (#6148 por @bakkot)

Añadir todos y solo los paréntesis necesarios al combinar new con llamadas a funciones es complejo. Este cambio corrige dos casos donde se omitieron paréntesis necesarios y otro donde se añadieron redundantes.

// Input
new (x()``.y)();
new (x()!.y)();
new e[f().x].y()

// Output (Prettier stable)
new x()``.y();
new x()!.y();
new e[(f()).x].y();

// Output (Prettier master)
new (x())``.y();
new (x())!.y();
new e[f().x].y();

Corrección de embebidos anidados (JS en HTML en JS) (#6038 por @thorn0)

Anteriormente, si código JS embebido en HTML (vía <script>) que a su vez estaba embebido en JS (vía un literal de plantilla) contenía literales de plantilla, el JS interno no se formateaba.

// Input
const html = /* HTML */ `<script>var a=\`\`</script>`;

// Output (Prettier stable)
// SyntaxError: Expecting Unicode escape sequence \uXXXX (1:8)

// Output (Prettier master)
const html = /* HTML */ `
  <script>
    var a = \`\`;
  </script>
`;

Mantener paréntesis necesarios alrededor de expresiones bind pasadas a expresiones new (#6152 por @sosukesuzuki)

Previamente, Prettier eliminaba los paréntesis necesarios alrededor de una expresión bind si se pasaba a una expresión new.

// Input
new (a::b)();

// Output (Prettier stable)
new a::b();

// Output (Prettier master)
new (a::b)();

Evitar añadir paréntesis innecesarios alrededor de expresiones bind en propiedades de expresiones de miembros (#6159 por @duailibe)

// Input
f[a::b];

// Output (Prettier stable)
f[(a::b)];

// Output (Prettier master);
f[a::b];

TypeScript

Conservar coma final en parámetros de tipo TSX (#6115 por @sosukesuzuki)

Anteriormente, se eliminaba una coma final después de un único parámetro de tipo en funciones flecha. El resultado formateado es válido en TS, pero inválido en TSX. Esto se corrigió en la versión 1.19.

// Input
type G<T> = any;
const myFunc = <T,>(arg1: G<T>) => false;

// Output (Prettier stable)
type G<T> = any;
const myFunc = <T>(arg1: G<T>) => false;

// Output (prettier master)
type G<T> = any;
const myFunc = <T,>(arg1: G<T>) => false;

No dividir expresiones de llamada cuando el último argumento es una función flecha con tipo de retorno simple (#6106 por @brainkim)

Corrige un caso extremo donde se dividían expresiones de llamada que contenían funciones flecha con tipos de retorno simples.

app.get("/", (req, res): void => {
  res.send("Hello World!");
});

// Output (Prettier stable)
app.get(
  "/",
  (req, res): void => {
    res.send("Hello World!");
  },
);

// Output (Prettier master)
app.get("/", (req, res): void => {
  res.send("Hello World!");
});

Conservar un par de paréntesis cuando hay pares adicionales (#6131 por @sosukesuzuki)

Previamente, Prettier eliminaba paréntesis necesarios al intentar quitar paréntesis innecesarios en TypeScript.

// Input
type G = ((keyof T))[];

// Output (Prettier stable)
type G = keyof T[];

// Output (prettier master)
type G = (keyof T)[];

Mantener paréntesis necesarios alrededor de aserciones no nulas (#6136 por @sosukesuzuki, #6140 por @thorn0, #6148 por @bakkot)

Anteriormente, Prettier eliminaba paréntesis necesarios alrededor de aserciones no nulas si el resultado de la expresión se usaba como constructor.

// Input
const b = new (c()!)();

// Output (Prettier stable)
const b = new c()!();

// Output (Prettier master)
const b = new (c())!();

Conservar saltos de línea en tipos mapeados (#6146 por @sosukesuzuki)

Previamente, Prettier eliminaba saltos de línea dentro de tipos mapeados. Para alinearlo con cómo tratamos objetos literales, conservaremos los saltos de línea si existían en el código fuente.

// Input
type A<T> = {
  readonly [P in keyof T]: T[P];
};

// Output (Prettier stable)
type A<T> = { readonly [P in keyof T]: T[P] };

// Output (Prettier master)
type A<T> = {
  readonly [P in keyof T]: T[P];
};

Añadir coma final en tipos tupla con --trailing-comma=all (#6172 por @sosukesuzuki)

TypeScript soporta coma final en tipos tupla desde la versión 3.3.

// Input
export type Foo = [
  number,
  number, // comment
];

// Output (Prettier stable)
export type Foo = [
  number,
  number // comment
];

// Output (Prettier master);
export type Foo = [
  number,
  number, // comment
];

Markdown

Determinar correctamente el número de backticks en código en línea (#6110 por @belochub)

Según la especificación CommonMark, se requiere 'elegir una cadena de n caracteres backtick como delimitadores, donde el código no contenga ninguna cadena de exactamente n backticks'.

Este cambio reemplaza el método anterior (usar 2 backticks cuando hay una cadena de backtick de longitud 1 dentro del bloque de código en línea, y 1 backtick en otros casos) por encontrar la longitud mínima de cadena backtick que pueda usarse correctamente como delimitador.

<!-- Input -->
``` 3 ``22`` `1` ```

`` 2 ```123``` `1` ``

<!-- Output (Prettier stable) -->
` 3 ``22`` `1` `

` 2 ```123``` `1` `

<!-- Output (Prettier master) -->
``` 3 ``22`` `1` ```

`` 2 ```123``` `1` ``

Handlebars

Aunque el soporte para Handlebars sigue en beta, @GavinJoyce está implementando correcciones para alcanzar finalmente una versión estable.

Evitar añadir espacios no deseados después de componentes (#6178 por @GavinJoyce)

Previamente, Prettier añadía un espacio antes de /> y un salto de línea después, incluso al inicio de línea. Ahora ese espacio extra y salto de línea ya no están presentes.

// Input
<div>
  <UserGreeting
    @aVeryLongArgumentNameThatIsStillGoing={{@alsoAVeryLongArgument}}
  />
</div>

// Output (Prettier stable)
<div>
  <UserGreeting
    @aVeryLongArgumentNameThatIsStillGoing={{@alsoAVeryLongArgument}}
   />

</div>

// Output (Prettier master)
<div>
  <UserGreeting
    @aVeryLongArgumentNameThatIsStillGoing={{@alsoAVeryLongArgument}}
  />
</div>

API

Prettier ahora vuelve a funcionar en Atom (#6129 por @duailibe)

Atom tiene una característica de seguridad que impide ejecutar código que contenga eval. Una dependencia de Prettier usaba eval para evitar que los empaquetadores incluyeran código de depuración. Ahora nos aseguramos que este eval no forme parte del código publicado en npm, permitiendo que Prettier vuelva a funcionar correctamente en Atom.