JavaScript-formatter

Plak een blok geminificeerde of slecht ingesprongen JavaScript en krijg schone, leesbare code terug, opgemaakt volgens dezelfde regels die editors gebruiken. Kies tabs of spaties, enkele of dubbele aanhalingstekens, wel of geen puntkomma’s en volgkomma’s in ES5 of overal. Verwerkt moderne syntaxis: optional chaining, nullish coalescing, JSX, TypeScript en top-level await.

JavaScript formatteren

  1. 1

    Plak de broncode

    Elke geldige JS, JSX of TypeScript. De parser bepaalt het dialect aan de hand van de syntaxis.

  2. 2

    Stel je voorkeuren in

    Inspringgrootte, tabs of spaties, aanhalingsstijl, puntkomma's, regelbreedte en volgkomma's.

  3. 3

    Formatteren

    De tool voert een Prettier-compatibele bewerking uit en geeft het opgemaakte resultaat terug.

  4. 4

    Kopieer de uitvoer

    Kopieer met één klik of download als bestand. De oorspronkelijke inspringing wordt weggegooid, niet erbovenop gelegd.

Stijlopties

Optie Waarden Standaard
Inspringing tab, 2, 4 2 spaties
Aanhalingsstijl single, double dubbel
Puntkomma’s always, never altijd
Regelbreedte 60 - 120 80
Volgkomma’s none, es5, all es5
Haakjes bij arrow-functies always, avoid altijd
Spatie binnen accolades true, false true
Enkele aanhalingstekens in JSX true, false false

Waarom opmaak ertoe doet

Opmaak is niet cosmetisch, het gaat om het verlagen van de cognitieve belasting. Een consistent opgemaakte codebase laat reviewers zich richten op de logische wijziging, niet op de zoektocht naar een verkeerd geplaatste accolade.

  • Muggenzifterij stopt zodra een project een formatter invoert. git diff toont de echte wijziging, niet de discussies over inspringing.
  • Pre-commit-hooks (met tools als Husky + lint-staged) formatteren gestagede bestanden automatisch vóór het committen.
  • Editor-integratie (VS Code, WebStorm) past dezelfde regels toe bij het opslaan.

Wat opmaak niet doet

  • Het lint niet. Stijlregels (no-unused-vars, eqeqeq) zijn het terrein van ESLint. Een formatter herschikt alleen witruimte en interpunctie, hij weigert geen code vanwege logische problemen.
  • Het herstelt geen syntaxisfouten. Als de invoer ongeldige JS is, geeft de formatter een fout. Gebruik het als een snelle controle dat je code op zijn minst parseert.
  • Het dwingt geen naamgevingsconventies af. camelCase versus snake_case is een lint-regel, geen formatter-regel.

Veelgemaakte fouten

  • Vechten tegen de formatter. Als je na afloop steeds opnieuw opmaakt, verspillen jullie allebei tijd. Configureer de opties of accepteer de keuze van het project.
  • Opmaak draaien op een gegenereerd bestand. Bundler-uitvoer, getranspileerde code, .min.js, geen van alle heeft er baat bij. Formatteer bronnen, geen artefacten.
  • Formatteren zonder parsen. Een “pretty-print” op basis van regex beschadigt template-literals, regex-literals en JSX. Gebruik altijd een op AST gebaseerde formatter (zoals deze).

Veelgestelde vragen

Ja. De parser herkent TypeScript-syntaxis (typen, interfaces, generics, decorators) en maakt dienovereenkomstig op. JSX wordt ook ondersteund in .tsx- / .jsx-bestanden.

Het volgt dezelfde regels als de standaardinstellingen van Prettier, instelbaar via de gebruikelijke opties (regelbreedte, aanhalingstekens, puntkomma’s, volgkomma’s). Een hier opgemaakt bestand hoort overeen te komen met een door Prettier opgemaakt bestand met dezelfde configuratie.

De formatter vereist geldige, parseerbare JavaScript. Als je een fout krijgt, heeft de code waarschijnlijk een syntaxisprobleem (niet-gesloten accolade, ongeldige JSX, typefout). Haal de code eerst door een linter als de melding onduidelijk is.

Ja. Zowel regelcommentaar (//) als blokcommentaar (/* */) blijft behouden in de uitvoer, dicht bij de plek waar het in de bron stond.

Gerelateerde tools

Tool beschikbaar in andere talen