Comfy-Org/ComfyUI_frontend
1
0
Fork 0
mirror of https://github.com/Comfy-Org/ComfyUI_frontend.git synced 2026-02-03 14:54:37 +00:00
Code Issues Packages Projects Releases Wiki Activity
5,779 Commits 581 Branches 533 Tags
devtools/refactor-devtools-nodes
Commit Graph

4 Commits

Author SHA1 Message Date
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
sno
187f59eed3 [fix] Remove pnpm cache from release-version-bump workflow (#6199) 
## Summary
- Fixed the "Post Setup Node.js" failure in the release-version-bump
workflow
- Removed unnecessary pnpm cache configuration that was causing
validation errors

fixes this JOB
- [Release: Version Bump · Comfy-Org/ComfyUI_frontend@2e8e136](
https://github.com/Comfy-Org/ComfyUI_frontend/actions/runs/18695441150/job/53311521564
)
<img width="1361" height="229" alt="image"
src="https://github.com/user-attachments/assets/22f780f0-59b8-4e57-ad9b-540683289a10"
/>


## Problem
The workflow was failing with error: "Path(s) specified in the action
for caching do(es) not exist, hence no cache is being saved."

This occurred because `setup-node@v4` with `cache: 'pnpm'` expects the
pnpm store directory to exist, but the workflow never runs `pnpm
install`. The workflow only executes `pnpm version`, which doesn't
require dependencies to be installed.

## Solution
Removed the `cache: 'pnpm'` configuration from the Setup Node.js step
since:
1. The workflow doesn't install dependencies
2. The cache provides no benefit for this workflow
3. It was causing the post-setup cleanup step to fail

## Test Plan
- [ ] Verify workflow runs successfully without cache errors
- [ ] Confirm version bump functionality still works correctly

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

┆Issue is synchronized with this [Notion
page](https://www.notion.so/PR-6199-fix-Remove-pnpm-cache-from-release-version-bump-workflow-2946d73d3650813dae7cf987a800e28b)
by [Unito](https://www.unito.io)

Co-authored-by: Claude <noreply@anthropic.com>
 2025-10-21 23:42:56 -07:00
Christian Byrne
c6b528b8be [ci] allow manual workflow dispatch to do version bumping on core branches (rather than just on main) (#6117) 
## Summary

Added configurable base branch selection to version bump workflows,
enabling patch releases from `core/*` branches via GitHub Actions UI.

## Changes

- **What**: Extended [workflow_dispatch
inputs](https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#workflow_dispatch)
with `branch` parameter for both main frontend and desktop-ui version
bump workflows
- **Validation**: Added branch existence check that lists available
`core/*` branches on error
- **Workflow modifications**:
- `release-version-bump.yaml`: Checkout and create PRs targeting
user-specified branch
- `version-bump-desktop-ui.yaml`: Same behavior for desktop-ui releases

## Review Focus

Branch validation logic correctly handles both local (`refs/heads/`) and
remote (`refs/remotes/origin/`) refs. Default value preserves backward
compatibility for release sheriffs unfamiliar with new feature.

## Use Case

Previously, patch releases from `core/1.29` required manual version
bumping. Now maintainers can trigger from Actions UI with dropdown
selections.

┆Issue is synchronized with this [Notion
page](https://www.notion.so/PR-6117-ci-allow-manual-workflow-dispatch-to-do-version-bumping-on-core-branches-rather-than-j-2906d73d365081cba3aff46471206a9e)
by [Unito](https://www.unito.io)
 2025-10-18 13:04:49 -07:00
snomiao
8cc5b52c64 refactor: reorganize GitHub workflows with consistent naming convention (#5891) 
## Summary

This PR implements a systematic naming convention for all GitHub
workflows to improve organization and discoverability. All 22 workflows
have been renamed and grouped by logical categories with consistent
prefixes.

## Changes

### Naming Convention
- **`ci-*`**: Continuous Integration workflows (testing, linting,
validation)
- **`pr-*`**: PR-specific automation triggered by labels  
- **`release-*`**: Release management workflows
- **`types-*`**: TypeScript type generation workflows
- **`i18n-*`**: Internationalization workflows

### Key Renames
- `tests-ci.yaml` → `ci-tests-e2e.yaml`
- `vitest-tests.yaml` → `ci-tests-unit.yaml`
- `storybook-and-chromatic-ci.yaml` → `ci-tests-storybook.yaml`
- `auto-backport.yaml` → `pr-backport.yaml`
- `claude-pr-review.yml` → `pr-claude-review.yaml`
- `version-bump.yaml` → `release-version-bump.yaml`
- `publish-frontend-types.yaml` → `release-npm-types.yaml`
- `create-dev-pypi-package.yaml` → `release-pypi-dev.yaml`

### Test Workflow Improvements
- Grouped all test workflows under `ci-tests-*` pattern
- Fork-safe deployment workflows: `ci-tests-e2e-forks.yaml`,
`ci-tests-storybook-forks.yaml`
- Added comments explaining fork deployment security workarounds

### Documentation
- Added comprehensive `.github/workflows/README.md`
- Documents naming conventions, best practices, and workflow
organization
- Includes trigger patterns and external dependencies

## Benefits

1. **Better Organization**: Workflows are now grouped logically by
prefix
2. **Improved Discoverability**: Easy to find related workflows  
3. **Consistent Naming**: All workflows follow the same pattern
4. **Clear Purpose**: Workflow names immediately indicate their function
5. **Maintainable**: README provides guidelines for future workflows

## Test Plan

- [x] All workflow cross-references updated
- [x] Display names match new file names  
- [x] Fork deployment workflows properly reference main workflows
- [x] Release workflows reference correct npm types workflow
- [x] All workflows retain original functionality

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

┆Issue is synchronized with this [Notion
page](https://www.notion.so/PR-5891-refactor-reorganize-GitHub-workflows-with-consistent-naming-convention-2806d73d365081febe47c7511bf0507e)
by [Unito](https://www.unito.io)

---------

Co-authored-by: Claude <noreply@anthropic.com>
Co-authored-by: Alexander Brown <drjkl@comfy.org>
 2025-10-17 08:32:33 +09:00