Prettier Formatting

Trovella uses Prettier 3.8 for automated code formatting. Formatting is enforced at two points: pre-commit hooks auto-format staged files, and CI runs a check-only pass that fails on any unformatted code.

Configuration

The root .prettierrc file defines all formatting rules:

{
  "semi": true,
  "trailingComma": "all",
  "singleQuote": false,
  "printWidth": 100,
  "tabWidth": 2,
  "useTabs": false,
  "bracketSpacing": true,
  "arrowParens": "always",
  "endOfLine": "lf",
  "plugins": ["prettier-plugin-tailwindcss"],
  "tailwindStylesheet": "./apps/web/src/app/globals.css"
}

Rule Rationale

Setting	Value	Why
semi	true	Explicit semicolons prevent ASI edge cases
trailingComma	"all"	Cleaner diffs -- adding an item does not modify the previous line
singleQuote	false	Double quotes are the default; consistent with JSON and JSX attributes
printWidth	100	Wider than the 80-char default; matches the ESLint max-lines spirit of readable but not excessively long lines
tabWidth	2	Standard for TypeScript/JavaScript projects
useTabs	false	Spaces for consistent rendering across editors and terminals
bracketSpacing	true	{ foo } not {foo} -- improves readability of object literals
arrowParens	"always"	(x) => x not x => x -- consistent and easier to add parameters
endOfLine	"lf"	Unix line endings; prevents Windows CRLF from entering the repo

Tailwind CSS Plugin

The prettier-plugin-tailwindcss plugin sorts Tailwind utility classes in a canonical order. It reads the project's Tailwind configuration from ./apps/web/src/app/globals.css (the tailwindStylesheet option) to resolve custom utilities and theme values.

This means any className string containing Tailwind utilities gets automatically reordered on save or pre-commit. The ordering follows Tailwind's recommended class order (layout, spacing, typography, visual, etc.).

File Type Coverage

Prettier formats the following file types:

*.ts, *.tsx, *.js, *.jsx, *.mjs, *.cjs, *.json, *.md, *.mdx, *.yml, *.yaml, *.css

This glob is used in both the format and format:check scripts in the root package.json:

{
  "format": "prettier --write \"**/*.{ts,tsx,js,jsx,mjs,cjs,json,md,mdx,yml,yaml,css}\"",
  "format:check": "prettier --check \"**/*.{ts,tsx,js,jsx,mjs,cjs,json,md,mdx,yml,yaml,css}\""
}

Ignored Paths

The .prettierignore file excludes generated and build output:

.next/
out/
dist/
build/
node_modules/
*.generated.ts
drizzle/migrations/
pnpm-lock.yaml
.turbo/
coverage/

Notable exclusions:

• drizzle/migrations/ -- generated SQL files should not be reformatted
• *.generated.ts -- any generated TypeScript files (convention: use .generated.ts suffix)
• pnpm-lock.yaml -- the lockfile has its own format
• .turbo/ -- Turborepo cache directory

How Formatting Runs

Pre-commit (automatic)

The lint-staged configuration in .lintstagedrc.mjs runs Prettier on staged files:

• .ts and .tsx files: Prettier runs after ESLint --fix, so ESLint fixes are also formatted
• All other supported file types (.js, .json, .md, .mdx, .yml, .yaml, .css): Prettier runs directly with --write

See Pre-commit Hooks for the full pipeline.

CI (check only)

The CI workflow runs pnpm format:check as the first step in the quality job. This uses Prettier's --check flag, which exits with a non-zero code if any file is not formatted correctly. It does not modify files.

If CI fails on formatting, run pnpm format locally, commit the result, and push again.

Manual (full repo)

Run pnpm format from the repo root to format every file in the monorepo. This is useful after bulk refactors or when resolving merge conflicts that introduced formatting drift.

Interaction with ESLint

Prettier and ESLint have overlapping concerns around formatting-adjacent rules (semicolons, quotes, spacing). To prevent conflicts, every ESLint preset in @repo/eslint-config ends with eslint-config-prettier, which disables all ESLint rules that would conflict with Prettier's output.

The division of responsibility:

• Prettier handles all formatting: indentation, line breaks, spacing, quotes, semicolons
• ESLint handles code quality: unused variables, type safety, naming conventions, complexity

If you see an ESLint rule that appears to be about formatting (e.g., indentation or brace style), it is likely already disabled by eslint-config-prettier. Do not add formatting rules to ESLint configs.