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

> Format code in OpenWork effortlessly with Prettier. Learn how to auto-format TypeScript, TSX, and Markdown, and enforce compliance with CI for cleaner code.

- Repository: [Different AI/openwork](https://github.com/different-ai/openwork)
- Tags: how-to-guide
- Published: 2026-08-01

---

**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`](https://github.com/different-ai/openwork/blob/main/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`](https://github.com/different-ai/openwork/blob/main/package.json) defines a `format` script that executes Prettier across the entire workspace. To format your changes before committing, run:

```bash
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:

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

```

Becomes properly structured code:

```typescript
// 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:

```bash
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`](https://github.com/different-ai/openwork/blob/main/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:

```markdown

```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.