@pmcx/standards

@pmcx/standards

Shared code quality configurations and development standards for the pmcx workspace, ensuring consistency across all packages and applications.

Purpose

This package centralizes ESLint, Prettier, and TypeScript configuration, providing a single source of truth for code style, linting rules, and type-checking standards. By sharing these configurations, we ensure that all workspace packages follow the same conventions, making code review easier and reducing cognitive overhead when switching between projects.

Contents

ESLint Configurations (eslint/)

• base.js – Core ESLint rules for TypeScript projects, including recommended patterns and common best practices
• react.js – Additional rules for React applications, including hooks validation and JSX patterns
• next.js – Next.js-specific rules and configurations (prepared for future web runtime)

Prettier Configuration (prettier/)

• index.js – Shared formatting rules for consistent code style across the workspace

TypeScript Configurations (typescript/)

• base.json – Base TypeScript compiler options for strict type checking
• react.json – React-specific TypeScript settings extending the base configuration
• next.json – Next.js-specific TypeScript settings (prepared for future web runtime)

Usage

Packages extend the appropriate configuration based on their requirements:

For base TypeScript projects:

// eslint.config.js
import {config} from '@pmcx/standards/eslint/base'

export default [...config]

For React applications:

// eslint.config.js
import {config} from '@pmcx/standards/eslint/react'

export default [...config]

TypeScript configuration:

// tsconfig.json
{
  "extends": "@pmcx/standards/typescript/react.json",
  "compilerOptions": {
    // Project-specific overrides
  }
}

Prettier:

// prettier.config.cjs
module.exports = require('@pmcx/standards/prettier')

Development

This package is versioned and published internally within the workspace. When updating standards, consider the impact on all consuming packages and communicate breaking changes appropriately.

Principles

Consistency Over Preference – These standards represent agreed-upon conventions for the team. Individual preferences should be set aside in favor of workspace-wide consistency.

Strictness by Default – Configurations err on the side of strictness, catching potential issues early. Projects can selectively relax rules when justified.

Composability – Configurations are designed to be extended and composed, allowing projects to add specific rules without duplicating base configurations.