Files
ComfyUI_frontend/CLAUDE.md
sno 02d303c039 [chore] Add Oxc linter to project (#6197)
## Summary
- Adds [Oxc linter](https://oxc.rs/docs/guide/usage/linter) as a dev
dependency
- Creates minimal `.oxlintrc.json` configuration file
- Integrates oxlint into the lint workflow (runs before ESLint)
- Adds `pnpm oxlint` script for standalone usage
- **NEW**: Adds
[eslint-plugin-oxlint](https://github.com/oxc-project/eslint-plugin-oxlint)
to disable redundant ESLint rules
- Updates `CLAUDE.md` documentation with oxlint command

## Motivation
Oxc is a high-performance Rust-based linter that is 50-100x faster than
ESLint. By integrating it into our lint workflow, we get:
- **Faster CI/CD pipelines** (5% improvement in this codebase)
- **Quicker local development feedback**
- **Additional code quality checks** that complement ESLint
- **Reduced duplicate work** by disabling ESLint rules that oxlint
already checks

## Changes
- **package.json**: Added `oxlint` and `eslint-plugin-oxlint` to
devDependencies, integrated into `lint`, `lint:fix`, and `lint:no-cache`
scripts
- **pnpm-workspace.yaml**: Added `eslint-plugin-oxlint` and
`mixpanel-browser` to catalog
- **eslint.config.ts**: Integrated `eslint-plugin-oxlint` to
automatically disable redundant ESLint rules
- **.oxlintrc.json**: Created minimal configuration file with schema
reference
- **CLAUDE.md**: Added `pnpm oxlint` to Quick Commands section
- **.gitignore**: Added `core` dump files

## CI/CD Performance Benchmark

Real-world CI/CD timing from GitHub Actions workflow runs:

### Baseline (ESLint only) - [Run
#18718911051](https://github.com/Comfy-Org/ComfyUI_frontend/actions/runs/18718911051)
- Run ESLint with auto-fix: **125s**
- Final validation (lint + format + knip): **16s**
- **Total: 141s**

### With Oxlint (oxlint + ESLint) - [Run
#18719037963](https://github.com/Comfy-Org/ComfyUI_frontend/actions/runs/18719037963)
- Run ESLint with auto-fix (includes oxlint): **118s**
- Final validation (includes oxlint + lint + format + knip): **16s**
- **Total: 134s**

### Results
 **7 seconds faster (5.0% improvement)** despite running an additional
linting pass

### Analysis
The oxlint integration actually **improves** CI/CD performance by ~5%.
This unexpected improvement is likely because:
1. **Oxlint catches issues early**: Some code that would have slowed
down ESLint's parsing/analysis is caught by oxlint first
2. **ESLint cache benefits**: The workflow uses `--cache`, and oxlint's
fast execution helps populate/validate the cache more efficiently
3. **Parallel processing**: Modern CI runners can overlap some of the
I/O operations between oxlint and ESLint

Even if oxlint added overhead, the value proposition would still be
strong given its additional code quality checks and local development
speed benefits. The fact that it actually speeds up the pipeline is a
bonus.

## eslint-plugin-oxlint Performance Impact

Benchmark comparing ESLint performance with and without
eslint-plugin-oxlint:

### Baseline (ESLint without plugin) - [Run
#18723242157](https://github.com/Comfy-Org/ComfyUI_frontend/actions/runs/18723242157)
- Run ESLint with auto-fix: **122s** (2m 2s)
- Final validation: **17s**

### With eslint-plugin-oxlint - [Run
#18723675903](https://github.com/Comfy-Org/ComfyUI_frontend/actions/runs/18723675903)
- Run ESLint with auto-fix: **129s** (2m 9s)
- Final validation: **12s**

### Results
**Performance: +7 seconds ESLint, -5 seconds validation (net +2
seconds)**

The eslint-plugin-oxlint integration has a **minimal performance
impact** (+2 seconds total). The slight increase in ESLint time is
likely due to the additional plugin configuration overhead, while the
validation step is faster because fewer redundant lint warnings need to
be processed.

### Benefits
The small performance cost is outweighed by important benefits:
1. **Prevents duplicate work**: Disables ~50 ESLint rules that oxlint
already checks (e.g., `no-constant-condition`, `no-debugger`,
`no-empty`, etc.)
2. **Reduces noise**: Eliminates redundant lint warnings from two tools
checking the same thing
3. **Cleaner workflow**: One authoritative source for each type of lint
check
4. **Best practice**: Recommended by the Oxc project for ESLint + oxlint
integration
5. **Consistent results**: Ensures both tools don't conflict or give
contradictory advice

## Usage
```bash
# Run oxlint standalone
pnpm oxlint

# Run full lint workflow (oxlint + ESLint)
pnpm lint
pnpm lint:fix
```

## Notes
- Oxlint now runs as part of the standard `pnpm lint` workflow
- The configuration uses minimal rules by default (Oxc's philosophy is
"catch erroneous or useless code without requiring any configurations by
default")
- Oxlint provides fast feedback while ESLint provides comprehensive
checks
- eslint-plugin-oxlint automatically manages rule conflicts between the
two tools
- Both tools complement each other in the linting pipeline

🤖 Generated with [Claude Code](https://claude.com/claude-code)

┆Issue is synchronized with this [Notion
page](https://www.notion.so/PR-6197-chore-Add-Oxc-linter-to-project-2946d73d3650818cbb55ef9c0abdb9b9)
by [Unito](https://www.unito.io)

---------

Co-authored-by: Claude <noreply@anthropic.com>
Co-authored-by: GitHub Action <action@github.com>
Co-authored-by: DrJKL <DrJKL0424@gmail.com>
2025-11-12 13:13:41 -08:00

4.2 KiB

ComfyUI Frontend Project Guidelines

Repository Setup

For first-time setup, use the Claude command:

/setup_repo

This bootstraps the monorepo with dependencies, builds, tests, and dev server verification.

Prerequisites: Node.js >= 24, Git repository, available ports (5173, 6006)

Quick Commands

  • pnpm: See all available commands
  • pnpm dev: Start development server (port 5173, via nx)
  • pnpm typecheck: Type checking
  • pnpm build: Build for production (via nx)
  • pnpm lint: Linting (via nx)
  • pnpm oxlint: Fast Rust-based linting with Oxc
  • pnpm format: Prettier formatting
  • pnpm test:unit: Run all unit tests
  • pnpm test:browser: Run E2E tests via Playwright
  • pnpm test:unit -- tests-ui/tests/example.test.ts: Run single test file
  • pnpm storybook: Start Storybook development server (port 6006)
  • pnpm knip: Detect unused code and dependencies

Monorepo Architecture

The project now uses Nx for build orchestration and task management:

  • Task Orchestration: Commands like dev, build, lint, and test:browser run via Nx
  • Caching: Nx provides intelligent caching for faster rebuilds
  • Configuration: Managed through nx.json with plugins for ESLint, Storybook, Vite, and Playwright
  • Dependencies: Nx handles dependency graph analysis and parallel execution

Key Nx features:

  • Build target caching and incremental builds
  • Parallel task execution across the monorepo
  • Plugin-based architecture for different tools

Development Workflow

  1. First-time setup: Run /setup_repo Claude command
  2. Make code changes
  3. Run tests (see subdirectory CLAUDE.md files)
  4. Run typecheck, lint, format
  5. Check README updates
  6. Consider docs.comfy.org updates

Git Conventions

  • Use [prefix] format: [feat], [bugfix], [docs]
  • Add "Fixes #n" to PR descriptions
  • Never mention Claude/AI in commits

External Resources

Project Philosophy

  • Follow good software engineering principles
    • YAGNI
    • AHA
    • DRY
    • SOLID
  • Clean, stable public APIs
  • Domain-driven design
  • Thousands of users and extensions
  • Prioritize clean interfaces that restrict extension access

Repository Navigation

  • Check README files in key folders (tests-ui, browser_tests, composables, etc.)
  • Prefer running single tests for performance
  • Use --help for unfamiliar CLI tools

GitHub Integration

When referencing Comfy-Org repos:

  1. Check for local copy
  2. Use GitHub API for branches/PRs/metadata
  3. Curl GitHub website if needed

Settings and Feature Flags Quick Reference

Settings Usage

const settingStore = useSettingStore()
const value = settingStore.get('Comfy.SomeSetting')     // Get setting
await settingStore.set('Comfy.SomeSetting', newValue)   // Update setting

Dynamic Defaults

{
  id: 'Comfy.Example.Setting',
  defaultValue: () => window.innerWidth < 1024 ? 'small' : 'large'  // Runtime context
}

Version-Based Defaults

{
  id: 'Comfy.Example.Feature',
  defaultValue: 'legacy',
  defaultsByInstallVersion: { '1.25.0': 'enhanced' }  // Gradual rollout
}

Feature Flags

if (api.serverSupportsFeature('feature_name')) {  // Check capability
  // Use enhanced feature
}
const value = api.getServerFeature('config_name', defaultValue)  // Get config

Documentation:

  • Settings system: docs/SETTINGS.md
  • Feature flags system: docs/FEATURE_FLAGS.md

Common Pitfalls

  • NEVER use any type - use proper TypeScript types
  • NEVER use as any type assertions - fix the underlying type issue
  • NEVER use --no-verify flag when committing
  • NEVER delete or disable tests to make them pass
  • NEVER circumvent quality checks
  • NEVER use dark: or dark-theme: tailwind variants. Instead use a semantic value from the style.css theme, e.g. bg-node-component-surface
  • NEVER use :class="[]" to merge class names - always use import { cn } from '@/utils/tailwindUtil', for example: <div :class="cn('text-node-component-header-icon', hasError && 'text-danger')" />