Prettier al rescat: Dona format automàticament al teu codi i oblida’t de les discussions d’estil

Introducció

Quantes vegades has entrat en discussions amb el teu equip sobre si utilitzar cometes simples o dobles al teu codi TypeScript? O sobre la indentació als templates HTML dels teus components Angular? O si el punt i coma al final de la línia és realment necessari? Aquestes “guerres d’estil”, encara que semblin menors, consumeixen temps i energia en el desenvolupament d’aplicacions Angular, i poden portar a inconsistències a la base de codi que dificulten la lectura i el manteniment.

Als meus articles anteriors, vam explorar com Husky ens ajuda a automatitzar tasques als nostres commits de Git i com ESLint (juntament amb els seus plugins específics) vigila la qualitat i els possibles errors del nostre codi, especialment a l’ecosistema TypeScript d’Angular. Avui, aprofundirem en la tercera peça clau d’aquest trencaclosques per a un desenvolupament Angular modern i eficient: Prettier.

Encara que ja ho vam mencionar, en aquest article ens submergirem en què fa a Prettier tan especial, com configurar-lo a fons i, el més important, com integrar-lo perfectament amb les eines de linting d’Angular (@angular-eslint) i Husky per crear un flux de treball on el format del codi deixa de ser una preocupació. Prepara’t per dir adéu al formatatge manual i a les discussions d’estil als teus projectes Angular!

Què és exactament Prettier i per què l’hauries d’utilitzar? (Més enllà del bàsic)

Prettier s’autodefineix com un formatador de codi opinionat. Què significa això?

• Formatador de Codi: La seva única missió és agafar el teu codi font (TypeScript, HTML, CSS/SCSS, JSON, etc.) i reescriure’l seguint un conjunt de regles d’estil consistents. S’encarrega dels salts de línia, l’espaiat, les cometes, els punts i comes, els parèntesis, etc.
• Opinionat: Aquí rau la clau. Prettier no intenta ser infinitament configurable. Implementa un estil de codi força específic i ofereix només un nombre limitat d’opcions per modificar-lo.

La filosofia “Opinionada”: Un avantatge?

Absolutament! En el context d’Angular, on treballem amb TypeScript i plantilles HTML complexes, la naturalesa opinionada de Prettier és una gran fortalesa:

1. Elimina Discussions: En adoptar Prettier, l’equip accepta el seu estil tant per a TS com per a HTML. S’han acabat els debats sobre tabuladors vs. espais o la posició dels claudàtors (brackets) a les plantilles.
2. Consistència Total: Garanteix que tot el codi del projecte (components, serveis, mòduls, plantilles, estils) tingui exactament el mateix format. Això millora dràsticament la llegibilitat.
3. Menys Configuració de Format: No has de perdre temps definint centenars de regles de format a ESLint. Instal·les Prettier, ajustes unes poques opcions clau, i deixes que ell s’encarregui del com es veu el codi.
4. Facilita l’Adopció: És més fàcil per als nous membres de l’equip adaptar-se a l’estil del projecte Angular: és automàtic.

La diferència crucial amb @angular-eslint

És fonamental entendre la divisió de responsabilitats:

• @angular-eslint (i @typescript-eslint): Es centra en la qualitat del codi, la detecció d’errors i el compliment de les bones pràctiques específiques d’Angular i TypeScript. Busca patrons problemàtics (ús incorrecte de decoradors, cicles de vida, RxJS), variables no utilitzades, lògica complexa, etc. Pot tenir regles de format, però gestionar-les és tediós i propens a conflictes amb Prettier.
• Prettier: Es centra exclusivament en el format del codi (TS, HTML, CSS/SCSS, etc.). No li importa la lògica, només la presentació visual consistent.

La conclusió és clara: No són competidors, són companys. La millor pràctica moderna a Angular és utilitzar @angular-eslint per a la qualitat i les regles específiques del framework, i Prettier per al format, configurant-los perquè treballin junts.

Instal·lació i configuració “A fons”

1. Instal·lació:

Afegeix Prettier com a dependència de desenvolupament. És molt recomanable utilitzar l’opció --save-exact (o equivalent a Yarn) per evitar que actualitzacions menors automàtiques canviïn subtilment el format i generin soroll als commits.

# Usant npm
npm install --save-dev --save-exact prettier

# Usant yarn
yarn add --dev --exact prettier

2. Fitxer de configuració (.prettierrc):

Prettier buscarà un fitxer de configuració a l’arrel del teu projecte. Pots utilitzar diversos formats, però .prettierrc.json (o simplement .prettierrc amb JSON dins) és comú i fàcil d’entendre:

# Crea el fitxer (exemple amb JSON)
touch .prettierrc.json

Ara, explorem algunes de les opcions de configuració més importants on pots “aprofundir”:

• printWidth (default: 80): Longitud màxima de línia. Prettier intentarà trencar les línies que excedeixin aquest límit. Un valor comú avui dia podria ser 100 o 120.
• tabWidth (default: 2): Nombre d’espais per nivell d’indentació.
• useTabs (default: false): Si és true, utilitza tabuladors en lloc d’espais per a la indentació.
• semi (default: true): Afegeix punt i coma al final de les sentències. Si ho poses a false, els traurà on sigui segur fer-ho.
• singleQuote (default: false): Si és true, utilitza cometes simples en lloc de dobles per als strings (excepte en JSX per defecte).
• quoteProps (default: "as-needed"): Quan afegir cometes a les propietats dels objectes. "consistent" (si una propietat necessita cometes, totes les tindran) o "preserve" (respecta l’entrada) són altres opcions.
• jsxSingleQuote (default: false): Si és true, utilitza cometes simples en JSX.
• trailingComma (default: "es5"): Afegeix comes al final en arrays i objectes multilínia on sigui vàlid a ES5. "all" ho fa també en paràmetres de funció. "none" les treu. Utilitzar "es5" o "all" és genial per als diffs de Git, ja que afegir un nou element només canvia una línia.
• bracketSpacing (default: true): Imprimeix espais entre les claus en objectes literals: { foo: bar } vs {foo: bar}.
• bracketSameLine (default: false): Si és true, col·loca el > de tancament d’una etiqueta HTML/JSX/Vue multilínia al final de l’última línia, en lloc d’en una línia nova. (jsxBracketSameLine està obsolet).
• arrowParens (default: "always"): Afegeix parèntesis al voltant d’un únic paràmetre en funcions fletxa. "avoid" els treu: x => x vs (x) => x.
• endOfLine (default: "lf"): Controla els finals de línia. "lf" (Linux/macOS), "crlf" (Windows), "cr" (rar), "auto" (manté els existents). És important per a equips que treballen en diferents sistemes operatius; "lf" sol ser l’opció més segura i estàndard amb Git.
• Important per a HTML: Prettier també formatarà els teus fitxers .html. Les opcions com printWidth, tabWidth, bracketSameLine afecten directament com es veuen les teves plantilles.

Exemple de .prettierrc.json:

{
  "printWidth": 100,
  "tabWidth": 2,
  "useTabs": false,
  "semi": true,
  "singleQuote": true, // Preferència comuna a la comunitat TS/Angular
  "trailingComma": "es5",
  "bracketSpacing": true,
  "bracketSameLine": false, // Posa el ">" en una nova línia a l'HTML
  "arrowParens": "always",
  "endOfLine": "lf"
  // Prettier detecta automàticament els parsers per a TS i HTML
}

Recorda: La idea de Prettier és minimitzar la configuració. Comença amb els valors per defecte i ajusta només allò amb què el teu equip realment no estigui d’acord o necessiti canviar per alguna raó específica.

3. Ignorant codi (.prettierignore):

Igual que .gitignore, pots crear un fitxer .prettierignore per dir-li a Prettier quins fitxers o carpetes no ha de formatar. És útil per a node_modules, carpetes de build (dist, build, coverage), fitxers generats automàticament, o potser fitxers de configuració molt específics.

Exemple de .prettierignore:

# Ignora dependències i fitxers de build
node_modules
dist
build
coverage
.angular/cache

# Ignora fitxers específics
src/legacy/problematic-file.js
src/assets/generated-data.json

# Ignora tots els fitxers d'un tipus en una carpeta específica
src/generated/**/*.svg

També pots ignorar blocs específics de codi dins d’un fitxer utilitzant un comentari // prettier-ignore a TypeScript o a HTML, just abans del bloc. Fes-ho servir amb moderació, només quan el format automàtic realment trenqui alguna cosa o sigui molt poc llegible per a un cas molt particular.

// prettier-ignore
matrix = [
  1, 0, 0,
  0, 1, 0,
  0, 0, 1
];

Executant Prettier eficaçment

1. Des de la Línia de Comandes (CLI):

• Comprovar format: Útil en CI (Integració Contínua) o per verificar abans d’un commit.

# Comprova tots els fitxers suportats al projecte
npx prettier --check .
# O específicament TS i HTML a src/
npx prettier --check "src/**/*.{ts,html}"

• Formatar fitxers: Reescriu els fitxers aplicant el format.

# Formata tot 
npx prettier --write . 
# O específicament TS i HTML a src/ 
npx prettier --write "src/**/*.{ts,html}"

2. Scripts a package.json:

És una bona pràctica afegir scripts per facilitar l’execució:

// package.json
"scripts": {
  // ... altres scripts (ng serve, ng build...)
  "format": "prettier --write \"./src/**/*.{ts,html,scss,json,md}\"", // Ajusta patrons segons necessitis
  "check-format": "prettier --check \"./src/**/*.{ts,html,scss,json,md}\""
}

Ara pots executar npm run format o npm run check-format.

3. Integració amb l’Editor (La Màgia Succeeix Aquí!)

Aquesta és la forma més còmoda d’utilitzar Prettier en el dia a dia. Gairebé tots els editors moderns (VS Code, WebStorm, Sublime Text, etc.) tenen extensions per a Prettier.

• Instal·la l’Extensió: Cerca “Prettier” al marketplace del teu editor (p. ex. “Prettier – Code formatter” per a VS Code).
• Configura “Format on Save”: L’opció més popular és configurar el teu editor perquè formati automàticament el fitxer cada vegada que el guardes. A VS Code, això es fa a la configuració (JSON o UI):

// settings.json (VS Code) 
{ 
  "editor.formatOnSave": true,
  "editor.defaultFormatter": "esbenp.prettier-vscode", // Assegura't que sigui el default // Aplica Format on Save per als llenguatges d'Angular
  "[typescript]": {
    "editor.defaultFormatter": "esbenp.prettier-vscode"
  },
  "[html]": { // Per als templates d'Angular 
    "editor.defaultFormatter": "esbenp.prettier-vscode" 
  }, 
  "[scss]": { // Si utilitzes SCSS 
    "editor.defaultFormatter": "esbenp.prettier-vscode" 
  }, 
  // etc. per a json, md... }

• Utilitza la Versió del Projecte: Assegura’t que l’extensió del teu editor estigui configurada per utilitzar la versió de Prettier instal·lada al teu projecte (node_modules/prettier) en lloc d’una versió global. Això garanteix que tot l’equip utilitzi exactament la mateixa versió i regles. La majoria de les extensions ho fan per defecte avui dia.

Amb “Format on Save“, Prettier esdevé gairebé invisible. Simplement escrius el teu codi i en desar… Paf! Es formata automàticament.

La integració perfecta: Prettier + ESLint + Husky (Posant-ho tot junt)

Aquí és on connectem tot per a un flux de treball robust a Angular. L’objectiu és assegurar que ESLint (configurat amb @angular-eslint) gestioni la qualitat del codi i les regles específiques d’Angular/TypeScript, mentre que Prettier s’encarrega exclusivament del format, i Husky automatitza la verificació abans de cada commit.

1. Prettier amb @angular-eslint:

Necessitem que ESLint no interfereixi amb les regles de format de Prettier.

• Instal·la les dependències necessàries (si no les tens): Assegura’t de tenir instal·lats els paquets clau com eslint, @typescript-eslint/parser, @typescript-eslint/eslint-plugin, @angular-eslint/eslint-plugin, @angular-eslint/template-parser, @angular-eslint/eslint-plugin-template. Per a la integració amb Prettier, necessitaràs eslint-config-prettier (per desactivar regles conflictives) i opcionalment eslint-plugin-prettier (per reportar diferències de format com a errors d’ESLint).

npm install --save-dev eslint @typescript-eslint/parser @typescript-eslint/eslint-plugin @angular-eslint/eslint-plugin @angular-eslint/template-parser @angular-eslint/eslint-plugin-template eslint-config-prettier eslint-plugin-prettier
# O utilitzant ng add @angular-eslint/schematics si comences de zero i després afegint les de prettier

• Configura .eslintrc.json: La clau és utilitzar eslint-config-prettier per desactivar regles conflictives i opcionalment eslint-plugin-prettier per integrar la comprovació. L’estructura típica a Angular utilitza overrides per separar la configuració de TypeScript i HTML:

// .eslintrc.json
{
  "root": true,
  "ignorePatterns": ["projects/**/*"], // Ajusta según tu estructura (mono-repo o no)
  "plugins": [ // Añade 'prettier' aquí si usas eslint-plugin-prettier
    "prettier"
  ],
  "overrides": [
    {
      // Configuración para archivos TypeScript (*.ts)
      "files": ["*.ts"],
      "parser": "@typescript-eslint/parser",
      "parserOptions": {
        "project": ["tsconfig.json"], // Asegúrate que apunte a tu tsconfig
        "createDefaultProgram": true
      },
      "plugins": [
        "@typescript-eslint",
        "@angular-eslint"
        // 'prettier' se añade globalmente si se usa el plugin
      ],
      "extends": [
        "eslint:recommended",
        "plugin:@typescript-eslint/recommended",   // Reglas TS base
        "plugin:@angular-eslint/recommended",    // Reglas Angular para TS
        // ¡MUY IMPORTANTE! Poner al final para desactivar conflictos:
        "prettier" // Usa eslint-config-prettier
      ],
      "rules": {
        // Reglas específicas de Angular o TS que quieras añadir/modificar
        "@angular-eslint/directive-selector": ["error", { "type": "attribute", "prefix": "app", "style": "camelCase" }],
        "@angular-eslint/component-selector": ["error", { "type": "element", "prefix": "app", "style": "kebab-case" }],
        // Si usas eslint-plugin-prettier, añade esta regla:
        "prettier/prettier": "error" // Reporta diferencias de Prettier como errores ESLint
      }
    },
    {
      // Configuración para archivos de Plantilla (*.html)
      "files": ["*.html"],
      "parser": "@angular-eslint/template-parser",
      "plugins": [
        "@angular-eslint/template"
      ],
      "extends": [
        "plugin:@angular-eslint/template/recommended", // Reglas Angular para HTML
        "plugin:@angular-eslint/template/accessibility" // Opcional: Reglas de accesibilidad
        // Nota: Prettier formatea HTML directamente. No se suele poner 'prettier' aquí
        // en 'extends', ya que eslint-config-prettier se aplica globalmente
        // y afecta principalmente a reglas TS/JS que podrían chocar.
      ],
      "rules": {
        // Puedes añadir/sobrescribir reglas específicas de plantilla aquí
        // Si quieres reportar formato Prettier en HTML vía ESLint (menos común):
        // "prettier/prettier": ["error", { "parser": "angular" }]
      }
    }
  ]
}

• eslint-config-prettier (inclòs en posar “prettier” a extends al final de la secció TS) desactiva regles d’ESLint/@angular-eslint que xoquen amb Prettier.
• eslint-plugin-prettier (si l’afegeixes a plugins globalment i configures la regla “prettier/prettier”: “error” a la secció TS) fa que les diferències de format en fitxers TypeScript es reportin com a errors d’ESLint, visibles a l’editor i en executar eslint.

2. Prettier amb Husky (i lint-staged):

Assegura que només codi ben formatat i sense errors de lint arribi al teu repositori Git.

• Instal·la lint-staged:

npm install --save-dev lint-staged

• Configura lint-staged a package.json:
  Defineix quines comandes executar sobre els fitxers que estan a l’staging area de Git (.ts, .html, .scss, etc.).

// package.json
"lint-staged": {
  // Per a fitxers TypeScript i HTML
  "*.{ts,html}": [
    "eslint --fix",       // Primer arregla el que ESLint pugui (incloent format si utilitzes el plugin)
    "prettier --write"    // Assegura el format final amb Prettier (important si ESLint no ho cobreix tot)
  ],
  // Per a altres fitxers (SCSS, JSON, Markdown...) que Prettier suporti
  "*.{scss,css,json,md}": [
    "prettier --write"
  ]
}

(L’ordre eslint –fix / prettier –write pot necessitar ajustos segons la teva configuració exacta. Executar tots dos sol ser una estratègia segura per cobrir tots els casos. prettier –write assegura que el format final sigui el de Prettier, fins i tot si ESLint no el va aplicar completament).

• Configura el Hook pre-commit de Husky:

Assegura’t que el teu script a .husky/pre-commit executi lint-staged.

#!/bin/sh
. "$(dirname "$0")/_/husky.sh"

npx lint-staged

(I assegura’t que el fitxer tingui permisos d’execució: chmod +x .husky/pre-commit).

El flux complet a Angular:

Ara, quan un desenvolupador del teu equip faci git add i després git commit -m “missatge”, passarà el següent de forma automàtica:

1. Husky intercepta el commit i executa l’script pre-commit.
2. L’script pre-commit llança npx lint-staged.
3. lint-staged identifica els fitxers modificats a l’staging area que coincideixin amb els patrons configurats (.ts, .html, .scss…).
4. Executa les comandes associades (eslint –fix, prettier –write) només sobre aquests fitxers modificats.
5. Si les comandes tenen èxit (formaten i/o arreglen errors sense fallar), lint-staged acabarà amb èxit. Els fitxers potencialment modificats per les comandes s’inclouran automàticament al commit.
6. Si lint-staged té èxit, el commit es completarà amb els fitxers nets i formatats.
7. Si alguna de les comandes falla (p. ex., ESLint troba un error greu que no pot arreglar automàticament), lint-staged fallarà, l’script pre-commit fallarà, i el commit serà avortat, mostrant l’error al desenvolupador perquè el corregeixi abans d’intentar fer commit de nou.

Màgia! Tens un sistema robust i automàtic que garanteix que tot el codi que entra al teu repositori Angular està correctament formatat segons Prettier i compleix amb les regles de qualitat definides a @angular-eslint.

Conclusió

Prettier és molt més que un simple formatador; és una eina essencial en el desenvolupament modern d’Angular. Porta consistència automàtica al format del teu codi TypeScript, HTML i CSS/SCSS, redueix la fricció de l’equip eliminant debats d’estil, i allibera temps mental en treure’t la preocupació del format manual.

Quan es combina amb les potents regles de qualitat de @angular-eslint i l’automatització de Husky + lint-staged, formes un trio imbatible que eleva la qualitat, la llegibilitat i la mantenibilitat dels teus projectes Angular. Et permet a tu i al teu equip centrar-vos en el que realment importa: construir funcionalitats increïbles per a les teves aplicacions, sabent que la base de codi es manté neta i consistent de forma automàtica.

Si encara no has integrat Prettier al teu flux de treball Angular, ara és el moment perfecte per fer-ho! La inversió inicial en configuració es paga amb escreix en tranquil·litat i eficiència a llarg termini.

Crida a l’acció (CTA)

I tu? Ja utilitzes Prettier als teus projectes Angular? Quina configuració d’@angular-eslint i Prettier et funciona millor? Has tingut algun repte específic en la integració amb Husky o lint-staged? Comparteix la teva experiència i els teus consells als comentaris!

I si et vas perdre els articles anteriors sobre les altres eines clau d’aquest flux de treball:

• [Enllaç al teu article sobre Husky]
• Configurar ESLint a Angular per obtenir codi net i fàcil de mantenir