Code Quality & Linting (Oxlint)
Relevant source files
The following files were used as context for generating this wiki page:
The spoof project utilizes Oxlint, a high-performance JavaScript/TypeScript linter, as its primary tool for ensuring code quality and adherence to style guidelines. It is integrated into the development workflow to provide rapid feedback, complementing the TypeScript compiler's static analysis. The project follows a modern TypeScript standard, specifically targeting Node.js 24 with ESM module support.
Sources: CLAUDE.md:10-12, package.json:115, README.md:143-157
Linting Architecture and Integration
The linting system is designed to be fast and non-intrusive, integrated directly into the project's NPM scripts. Oxlint is configured to run across the entire repository, specifically targeting the TypeScript source files located in the src/ directory.
Core Linting Workflow
The workflow distinguishes between standard linting, auto-fixing, and strict validation. While Oxlint handles stylistic and common programmatic errors, the TypeScript compiler (tsc) is used in parallel for deep type checking.
The diagram shows the parallel paths for code quality: Oxlint for linting/fixing and TSC for type validation.
Sources: package.json:84-86, CLAUDE.md:31-33
Script Configuration
The package.json defines several entry points for quality checks:
| Script Name | Command | Purpose |
|---|---|---|
lint | oxlint . | Executes Oxlint across the project root. |
lint:fix | oxlint --fix . | Automatically fixes repairable linting issues. |
typecheck | tsc --noEmit | Validates types without generating output files. |
test | yarn build && yarn lint && vitest run | A composite script ensuring code is built and linted before testing. |
Sources: package.json:84-88
Style Guidelines
The project enforces specific stylistic choices through its linting and compiler configuration. Key rules include:
- No Semicolons: The codebase avoids trailing semicolons.
- Indentation: 2-space indentation is standard.
- Quotes: Single quotes are used for string literals.
- Module Format: ESM (ECMAScript Modules) is mandatory (
"type": "module").
Sources: CLAUDE.md:106-108, package.json:49
TypeScript Configuration
The tsconfig.json complements the linter by enforcing strict programmatic constraints that Oxlint might not cover:
| Field | Setting | Impact |
|---|---|---|
strict | true | Enables all strict type-checking options. |
noUnusedLocals | true | Reports errors on unused local variables. |
noImplicitReturns | true | Ensures all code paths in a function return a value. |
forceConsistentCasingInFileNames | true | Prevents issues on case-insensitive file systems. |
Sources: tsconfig.json:5-18
Validation and Pre-release Pipeline
The project uses a tiered validation system to ensure that no code with linting or type errors is committed or published.
Validation Tiers
- Standard Validation (
yarn validate): Combines building, linting, and unit testing. - Strict Validation (
yarn validate:strict): Adds explicit type checking (tsc --noEmit) to the standard validation. This is required forprepublishOnlyandpreversionhooks.
The sequence shows how multiple tools are orchestrated during the strict validation phase.
Sources: package.json:89-92, CLAUDE.md:35-37
Mutation Testing
Beyond static analysis and linting, the project employs Stryker Mutator to evaluate the effectiveness of the test suite. This ensures that the code quality isn't just "lint-clean" but also robustly tested.
- Runner: Vitest
- Coverage Analysis:
perTest - Target: All files in
src/(excluding types and declarations). - Reporting: Generates an HTML report at
reports/mutation/mutation.html.
Sources: stryker.config.json:2-15, package.json:96-97
Summary
Code quality in the spoof repository is maintained through a multi-layered approach centered on the performance of Oxlint. By combining fast linting with strict TypeScript compiler options and mutation testing via Stryker, the project ensures high standards of maintainability and reliability across macOS, Linux, and Windows platforms.