JavaScript-formaterare

Klistra in ett stycke minifierad eller dåligt indragen JavaScript och få tillbaka ren, läsbar kod formaterad enligt samma regler som editorer använder. Välj tabbar eller mellanslag, enkla eller dubbla citattecken, med eller utan semikolon, avslutande kommatecken i ES5 eller överallt. Hanterar modern syntax: valfri kedjning, null-sammanslagning, JSX, TypeScript och await på toppnivå.

Så formaterar du JavaScript

  1. 1

    Klistra in källkoden

    Vilken giltig JS, JSX eller TypeScript som helst. Parsern avgör dialekten utifrån syntaxen.

  2. 2

    Ställ in dina inställningar

    Indragsstorlek, tabbar eller mellanslag, citatstil, semikolon, radbredd och avslutande kommatecken.

  3. 3

    Formatera

    Verktyget kör en Prettier-kompatibel bearbetning och returnerar det formaterade resultatet.

  4. 4

    Kopiera utdata

    Kopiera med ett klick eller ladda ner som fil. Det ursprungliga indraget kasseras, det läggs inte ovanpå.

Stilalternativ

Alternativ Värden Standard
Indrag tab, 2, 4 2 mellanslag
Citatstil single, double dubbla
Semikolon always, never alltid
Radbredd 60 - 120 80
Avslutande kommatecken none, es5, all es5
Parenteser vid pilfunktioner always, avoid alltid
Mellanrum inom klamrar true, false true
Enkla citattecken i JSX true, false false

Varför formatering spelar roll

Formatering är inte kosmetika, det handlar om att minska den kognitiva belastningen. En enhetligt formaterad kodbas låter granskare fokusera på den logiska ändringen i stället för att jaga en felplacerad klammer.

  • Struntdiskussioner upphör så snart ett projekt inför en formaterare. git diff visar den faktiska ändringen, inte debatter om indrag.
  • Pre-commit-hookar (med verktyg som Husky + lint-staged) formaterar automatiskt de stagade filerna innan de committas.
  • Editorintegration (VS Code, WebStorm) tillämpar samma regler vid sparande.

Vad formatering inte gör

  • Den lintar inte. Stilregler (no-unused-vars, eqeqeq) är ESLints område. En formaterare omformar bara blanksteg och skiljetecken, den avvisar inte kod på grund av logikproblem.
  • Den rättar inte syntaxfel. Om indata är ogiltig JS kastar formateraren ett fel. Använd den som en rimlighetskontroll att din kod åtminstone går att parsa.
  • Den upprätthåller inga namngivningskonventioner. camelCase kontra snake_case är en lint-regel, inte en formateringsregel.

Vanliga misstag

  • Att slåss mot formateraren. Om du fortsätter formatera om efter att den körts slösar ni båda tid. Konfigurera antingen alternativen eller acceptera projektets val.
  • Att köra formatering på en genererad fil. Bundler-utdata, transpilerad kod, .min.js, ingen av dem tjänar på det. Formatera källor, inte artefakter.
  • Att formatera utan att parsa. En “pretty-print” baserad på regex förstör malliteraler, regex-literaler och JSX. Använd alltid en AST-baserad formaterare (som den här).

Vanliga frågor

Ja. Parsern upptäcker TypeScript-syntax (typer, gränssnitt, generics, dekoratorer) och formaterar därefter. JSX stöds även i .tsx- / .jsx-filer.

Den följer samma regler som Prettiers standardinställningar och kan konfigureras via de vanliga alternativen (radbredd, citattecken, semikolon, avslutande kommatecken). En fil som formaterats här ska stämma med en som formaterats av Prettier med samma konfiguration.

Formateraren kräver giltig, parsbar JavaScript. Om du får ett fel har koden troligen ett syntaxproblem (oavslutad klammer, ogiltig JSX, stavfel). Kör den genom en linter först om meddelandet är otydligt.

Ja. Både radkommentarer (//) och blockkommentarer (/* */) behålls i utdata och placeras nära där de låg i källan.

Relaterade verktyg

Verktyget finns på andra språk