code-style

Enforce Biome-based code style and TypeScript conventions in monorepos.

4.6k|378|Updated Jun 28, 2024
One-click install
npx skills add https://github.com/latitude-dev/latitude-llm --skill code-style-latitude-dev
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: code-style
Source: https://github.com/latitude-dev/latitude-llm/tree/main/.agents/skills/code-style
Command: npx skills add https://github.com/latitude-dev/latitude-llm --skill code-style-latitude-dev

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

Biome-based code style and strict TypeScript conventions help teams maintain consistent, high-quality code across large repositories.

Core Features & Use Cases

  • Biome config is the source of truth: indentation is 2 spaces, max line width 120, strings use double quotes, semicolons as needed, and ignore generated or output paths such as dist/, coverage/, .turbo/, node_modules/, **/*.gen.ts, and **/models.dev.json. The guide also advocates running package-local formatting with pnpm --filter @app/api format.
  • Imports: prefer static imports; avoid dynamic import patterns unless justified. Use import type for type-only imports. Keep imports explicit and grep-friendly. Preserve clear grouping/order (external, internal alias, then relative). Avoid wildcard exports/imports when explicit named exports are practical. Avoid barrel files (import from specific modules rather than index re-exports). Use .ts or .tsx extensions in relative imports.
  • TypeScript: base config is tsconfig.base.json; strict: true; Module system: NodeNext + ESM. For new domain data contracts, define canonical shared shape as a Zod schema first for runtime validation, then infer TypeScript types from that schema or from Drizzle schemas where appropriate. Treat schemas in src/entities/<entity>.ts as canonical domain contracts; reuse domain constants, field schemas, and literal unions where possible. Avoid TypeScript enums; prefer literal-string unions. Use shared domain schemas to validate boundary data; ensure boundary schemas align with entity shapes; keep inline limits minimal.
  • Naming and structure: prefer explicit domain types/interfaces; readonly fields for immutable domain data; methods with multiple args default to a single named-arguments object. React component file names should be kebab-case. Package names follow scoped workspace style, e.g., @app/, @domain/.
  • Domain module layout: canonical entity schemas in src/entities/<entity>.ts; domain constants in src/constants.ts; domain errors in src/errors.ts; small domain helpers in src/helpers.ts.
  • Generated files: routeTree.gen.ts is auto-generated; commit regenerated files when they change but do not edit by hand.
  • Generated conventions: Readability and maintainability are key; avoid unnecessary comments; keep abstractions minimal.

Quick Start

Follow these rules to format and structure your codebase according to Biome standards.

Frequently Asked Questions about code-style

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I enforce consistent code style and TypeScript conventions in a monorepo?

Configure Biome as the formatting source of truth with 2-space indentation, 120-character max line width, and double quotes to enforce consistent code style and TypeScript conventions across a monorepo.

What are the best import rules for TypeScript React components?

Prefer static imports, use `import type` for type-only imports, and maintain explicit grouping from external to relative paths with `.ts` or `.tsx` extensions for optimal TypeScript React component import rules.

Does Biome support strict TypeScript settings with NodeNext and ESM modules?

Biome supports strict TypeScript settings with NodeNext and ESM modules by applying a `tsconfig.base.json` configuration with `strict: true` alongside its formatting rules.

How do I structure domain schemas and data contracts in a TypeScript project?

Define canonical shared shapes as Zod schemas first for runtime validation, then infer TypeScript types from them, placing entity schemas in `src/entities/<entity>.ts` to structure domain data contracts.

Why should I avoid barrel files and wildcard exports in TypeScript?

Avoid barrel files and wildcard exports in TypeScript because explicit named imports from specific modules are more grep-friendly, readable, and prevent unnecessary coupling across the codebase.

Can I use Biome formatting for React components with kebab-case filenames?

Biome formatting works with React components using kebab-case filenames by enforcing consistent indentation, quote styles, and naming boundaries across TypeScript monorepos.