## Summary
Fixes Storybook rendering issue where all components fail to load with
`_sfc_main is not defined` error in **local development** since v1.29.3.
## Problem
After upgrading to v1.29.3, all Storybook components fail to render **in
local development** (`pnpm storybook`) with the following error:
```
ReferenceError: _sfc_main is not defined
The component failed to render properly, likely due to a configuration issue in Storybook.
```
**Important**: This issue only affects **local development**
environments. The deployed/built Storybook works correctly.
This affects both:
- Main Storybook (`pnpm storybook`)
- Desktop-ui Storybook instances
## Root Cause
In v1.29.3, commit `64430708e` ("perf: tree shaking and minify #6068")
enabled build optimizations in `vite.config.mts`:
```typescript
// Before (v1.29.2)
rollupOptions: {
treeshake: false
}
esbuild: {
minifyIdentifiers: false
}
// After (v1.29.3)
rollupOptions: {
treeshake: true // ⚠️ Enabled
}
esbuild: {
minifyIdentifiers: SHOULD_MINIFY // ⚠️ Conditionally enabled
}
```
While these optimizations are beneficial for production builds, they
cause issues in **Storybook's local dev server**:
1. **Tree-shaking in dev mode**: Rollup incorrectly identifies Vue SFC's
`_sfc_main` exports as unused code during the dev server's module
transformation
2. **Identifier minification**: esbuild minifies `_sfc_main` to shorter
names in development, breaking Storybook's HMR (Hot Module Replacement)
and dynamic module loading
Since Storybook's `main.ts` inherits settings from `vite.config.mts` via
`mergeConfig`, these optimizations were applied to Storybook's dev
server configuration, causing Vue components to fail rendering in local
development.
**Why deployed Storybook works**: Production builds have different
optimization pipelines that handle Vue SFCs correctly, but the dev
server's real-time transformation breaks with these settings.
## Solution
Added explicit build configuration overrides in both Storybook
configurations to ensure the **dev server** doesn't inherit problematic
optimizations:
**Files changed:**
- `.storybook/main.ts`
- `apps/desktop-ui/.storybook/main.ts`
**Changes:**
```typescript
esbuild: {
// Prevent minification of identifiers to preserve _sfc_main in dev mode
minifyIdentifiers: false,
keepNames: true
},
build: {
rollupOptions: {
// Disable tree-shaking for Storybook dev server to prevent Vue SFC exports from being removed
treeshake: false,
// ... existing onwarn config
}
}
```
This ensures Storybook's **local development server** prioritizes
stability and debuggability over bundle size optimization, while
production builds continue to benefit from tree-shaking and
minification.
## Testing
1. Cleared Storybook and Vite caches: `rm -rf .storybook/.cache
node_modules/.vite`
2. Started local Storybook dev server with `pnpm storybook`
3. Verified all component stories render correctly without `_sfc_main`
errors
4. Ran `pnpm typecheck` to ensure TypeScript compilation succeeds
5. Tested HMR (Hot Module Replacement) works correctly with component
changes
## Context
- This is a **local development-only** issue; deployed Storybook builds
work fine
- Storybook dev server requires special handling because it dynamically
imports and hot-reloads all stories at runtime
- Vue SFC compilation generates `_sfc_main` as an internal identifier
that must be preserved during dev transformations
- Development tools like Storybook benefit from unoptimized builds for
better debugging, HMR, and stability
- Production builds remain optimized with tree-shaking and minification
enabled
┆Issue is synchronized with this [Notion
page](https://www.notion.so/PR-6635-bugfix-Fix-Storybook-_sfc_main-undefined-error-after-v1-29-3-2a56d73d36508194a25eef56789e5e2b)
by [Unito](https://www.unito.io)
## Summary
Removes broken terminal toggle button that causes UX issues during
desktop installation.
## Changes
- **What**: Removes "Show Terminal" button from ServerStartView during
install flow
- **Breaking**: None (removes broken functionality)
## Review Focus
Cherry-picked from feb3c078f (v1.27.9). The button causes broken UX when
clicked during install. The working "Show Logs" button remains and takes
users directly to the log directory. This patch was written directly for
the release, in a rush to fix issues. The fix was not PR'd into main as
well (due to timing), so the original issue has now resurfaced.
## Summary
Removes "Desktop" suffix from the desktop app window title.
## Changes
- **What**: Changes window title from "ComfyUI Desktop" to "ComfyUI"
## Review Focus
Fixes title regression introduced during desktop UI separation.
## Summary
Fixes regression where desktop UI GPU picker images failed to load due
to incorrect absolute path resolution.
## Changes
- **What**: Converts absolute image paths to relative paths with `./`
prefix in GpuPicker component
- **Breaking**: None
## Review Focus
ESLint rule incorrectly flagged relative paths as errors, leading to use
of absolute paths that don't resolve correctly in desktop app context.
The change is just adding `.` to the start of two lines. ESLint rules
reorganised the rest.
┆Issue is synchronized with this [Notion
page](https://www.notion.so/PR-6178-Fix-asset-path-resolution-in-desktop-GPU-picker-2936d73d3650814e9d0df9faf8e28733)
by [Unito](https://www.unito.io)
## Summary
- Implement dynamic imports for internationalization (i18n) locale files
to reduce initial bundle size
- Only load English locale eagerly as default/fallback, load other
locales on-demand
- Apply code splitting to both main ComfyUI frontend and desktop-ui
applications
## Technical Details
- **Before**: All locale files (main.json, nodeDefs.json, commands.json,
settings.json) for all 9 languages were bundled in the initial
JavaScript bundle
- **After**: Only English locale files are included in initial bundle,
other locales are loaded dynamically when needed
- Implemented `loadLocale()` function that uses dynamic imports with
`Promise.all()` for efficient parallel loading
- Added locale tracking with `loadedLocales` Set to prevent duplicate
loading
- Updated both `src/i18n.ts` and `apps/desktop-ui/src/i18n.ts` with
consistent implementation
## Bundle Size Impact
This change significantly reduces the initial bundle size by removing ~8
languages worth of JSON locale data from the main bundle. Locale files
are now loaded on-demand only when users switch languages.
## Implementation
- Uses dynamic imports: `import('./locales/[locale]/[file].json')`
- Maintains backward compatibility with existing locale switching
mechanism
- Graceful error handling for unsupported locales
- No breaking changes to the public API
## Test plan
- [x] Verify initial load only includes English locale
- [x] Test dynamic locale loading when switching languages in settings
- [x] Confirm fallback behavior for unsupported locales
- [x] Validate both web and desktop-ui applications work correctly
🤖 Generated with [Claude Code](https://claude.ai/code)
┆Issue is synchronized with this [Notion
page](https://www.notion.so/PR-6076-feat-implement-dynamic-imports-for-locale-code-splitting-28d6d73d36508189ae0ef060804a5cee)
by [Unito](https://www.unito.io)
---------
Co-authored-by: Claude <noreply@anthropic.com>
## Summary
Extracts desktop UI into apps/desktop-ui package with minimal changes.
## Changes
- **What**:
- Separates desktop-specific code into standalone package with
independent Vite config, router, and i18n
- Drastically simplifies the main app router by removing all desktop
routes
- Adds a some code duplication, most due to the existing design
- Some duplication can be refactored to be *simpler* on either side - no
need to split things by `isElectron()`
- Rudimentary storybook support has been added
- **Breaking**: Stacked PR for publishing must be merged before this PR
makes it to stable core (but publishing _could_ be done manually)
- #5915
- **Dependencies**: Takes full advantage of pnpm catalog. No additional
dependencies added.
## Review Focus
- Should be no changes to normal frontend operation
- Scripts added to root package.json are acceptable
- The duplication in this PR is copied as is, wherever possible. Any
corrections or fix-ups beyond the scope of simply migrating the
functionality as-is, can be addressed in later PRs. That said, if any
changes are made, it instantly becomes more difficult to separate the
duplicated code out into a shared utility.
- Tracking issue to address concerns: #5925
### i18n
Fixing i18n is out of scope for this PR. It is a larger task that we
should consider carefully and implement properly. Attempting to isolate
the desktop i18n and duplicate the _current_ localisation scripts would
be wasted energy.
