How to Format Code in OpenWork: Prettier Workflow and CI Enforcement

Run pnpm format locally to auto-format TypeScript, TSX, and Markdown files using Prettier, then verify compliance with pnpm lint before submitting your PR.

OpenWork (different-ai/openwork) maintains strict code consistency through an automated Prettier-based workflow that enforces default styling rules across the entire repository. Whether you are modifying Electron UI components in apps/desktop/ or updating documentation in the docs/ folder, understanding how to format code in OpenWork ensures your contributions pass CI validation and match the codebase standards.

Understanding OpenWork's Formatting Standards

OpenWork adheres to Prettier's default configuration without custom overrides stored in the repository. The exact Prettier version is pinned in pnpm-lock.yaml to guarantee identical formatting across all developer environments.

The formatting rules apply to:

• TypeScript (.ts) and TSX (.tsx) files in apps/desktop/ and other packages
• JavaScript (.js) source files
• Markdown (.md) documentation files

Unlike projects that rely on .prettierrc files, OpenWork uses Prettier's built-in defaults, ensuring zero-configuration consistency throughout the monorepo.

Local Formatting with pnpm

The root package.json defines a format script that executes Prettier across the entire workspace. To format your changes before committing, run:

pnpm format

This command expands to prettier --write ., which automatically corrects indentation, trailing commas, semicolons, and line breaks in all supported files. For example, unformatted TypeScript like this:

// Before formatting
export function sum(a:number,b:number){return a+b;}

Becomes properly structured code:

// After running pnpm format
export function sum(a: number, b: number): number {
  return a + b;
}

Pre-Submission Validation

Before opening a pull request, verify that your changes meet the repository's quality gates. The CI pipeline runs these same checks and will fail if formatting deviations exist.

Execute the validation suite:

pnpm lint      # Runs ESLint with shared configuration

pnpm typecheck # Runs tsc to verify type safety against tsconfig.json

The lint step specifically flags formatting violations detected by Prettier integration, while typecheck ensures your TypeScript conforms to the compiler settings defined in the root tsconfig.json.

Formatting Markdown Documentation

When contributing to the docs/ folder or writing PR descriptions, use proper markdown code fences with language specifiers for syntax highlighting. Wrap code snippets in triple backticks and specify the language immediately after the opening backticks:

```tsx
import { Button } from "@/components/ui/button";

export function MyComponent() {
  return <Button>Click me</Button>;
}

This practice ensures rendered documentation retains readability and proper formatting across GitHub and other markdown viewers.

## Best Practices for Contributors

Follow these guidelines to maintain consistency with the OpenWork codebase:

- **Avoid manual whitespace adjustments.** Let Prettier handle line breaks, indentation, and trailing commas. Manual edits create unnecessary diffs that the formatter will correct in CI.
- **Format generated files.** Some packages contain auto-generated TypeScript files. Run `pnpm format` on the entire workspace to normalize both hand-written and generated code.
- **Verify Electron UI components.** When working in `apps/desktop/`, ensure your `.tsx` components pass the formatter before submission, as the CI lint step strictly enforces style compliance in the Electron UI source.

## Summary

- OpenWork uses **Prettier with default rules** (no custom configuration) to format TypeScript, TSX, JavaScript, and Markdown files.
- Run **`pnpm format`** locally to execute `prettier --write .` and auto-fix styling issues across the workspace.
- Validate changes using **`pnpm lint`** and **`pnpm typecheck`** before submitting PRs to ensure CI compliance.
- Write documentation code blocks with **triple backticks and language specifiers** (e.g., ` ```tsx `) for proper syntax highlighting.
- The root **`package.json`**, **`tsconfig.json`**, and **`pnpm-lock.yaml`** define the formatting toolchain and TypeScript compiler settings.

## Frequently Asked Questions

### What formatter does OpenWork use?

OpenWork uses **Prettier** with its default configuration. The exact version is pinned in `pnpm-lock.yaml` to ensure all contributors use identical formatting rules, and the `format` script in `package.json` invokes `prettier --write .` across the repository.

### How do I check if my code is properly formatted before submitting a PR?

Run **`pnpm lint`** to check for formatting violations and ESLint errors, then run **`pnpm typecheck`** to verify TypeScript compilation against `tsconfig.json`. These commands mirror the CI checks that run on pull requests.

### Does OpenWork use a custom Prettier configuration?

No. OpenWork relies on **Prettier's default settings** without a `.prettierrc` file or custom overrides. This zero-configuration approach ensures consistent styling across the `apps/desktop/` source, documentation files, and generated code.

### How should I format code blocks in OpenWork documentation?

Use triple backticks followed by the language identifier, such as ` ```ts ` or ` ```tsx `. This ensures proper syntax highlighting in the `docs/` folder and GitHub's rendered markdown view.

{
  "mcpServers": {
    "instagit": {
      "command": "npx",
      "args": ["-y", "instagit@latest"]
    }
  }
}