[refactor] Solve circular dependency in LiteGraph module

[snomiao]

Summary

• Extracted LiteGraph singleton instance into a separate module to break circular dependency chains
• Improves module loading order and prevents initialization issues
• Maintains the same API and functionality

Context

This PR addresses the second circular dependency issue mentioned in #5533:

• The circular import chain: SubgraphNode → LGraphNode → litegraph.ts → SubgraphNode
• When litegraph.ts exports modules, it triggers loading of SubgraphNode which tries to extend LGraphNode, but LGraphNode imports from litegraph.ts causing circular initialization

Solution

By extracting the LiteGraph singleton into a separate LiteGraphSingleton.ts module, we break the circular dependency chain and ensure proper module initialization order.

Changes

• Created new LiteGraphSingleton.ts module to hold the singleton instance
• Updated all imports across the codebase to reference the singleton from the new module
• No functional changes, purely a refactoring to improve module structure

Test Plan

• All existing tests pass
• No runtime errors from circular dependencies
• Module loading order is now deterministic

🤖 Generated with Claude Code

[github-actions]

🎭 Playwright Test Results

⚠️ Tests passed with flaky tests

⏰ Completed at: 09/24/2025, 03:00:45 AM UTC

📈 Summary

• Total Tests: 459
• Passed: 428 ✅
• Failed: 0
• Flaky: 2 ⚠️
• Skipped: 29 ⏭️

📊 Test Reports by Browser

• ✅ chromium: View Report • ✅ 421 / ❌ 0 / ⚠️ 2 / ⏭️ 29
• ✅ chromium-2x: View Report • ✅ 2 / ❌ 0 / ⚠️ 0 / ⏭️ 0
• ✅ chromium-0.5x: View Report • ✅ 1 / ❌ 0 / ⚠️ 0 / ⏭️ 0
• ✅ mobile-chrome: View Report • ✅ 4 / ❌ 0 / ⚠️ 0 / ⏭️ 0

---

🎉 Click on the links above to view detailed test results for each browser configuration.

[github-actions]

🔧 Auto-fixes Applied

This PR has been automatically updated to fix linting and formatting issues.

⚠️ Important: Your local branch is now behind. Run git pull before making additional changes to avoid conflicts.

Changes made:

• ESLint auto-fixes
• Prettier formatting

[webfiltered]

I might be misreading the PR - the current global LiteGraph object is already a singleton. Could you not just move that instead? It would be a significantly smaller change.

[snomiao]

I might be misreading the PR - the current global LiteGraph object is already a singleton. Could you not just move that instead? It would be a significantly smaller change.

Hey @webfiltered, You did not misreading!

I 've renamed it just wanna ensure we are importing direct from the module insteadof from barrel file litegraph.ts. Using a different name helps avoid any confusion between two export files in future.

I think better name is LiteGraphInternal now, just pushed new commit for it : D

[webfiltered]

I might be misreading the PR - the current global LiteGraph object is already a singleton. Could you not just move that instead? It would be a significantly smaller change.

Hey @webfiltered, You did not misreading!

I 've renamed it just wanna ensure we are importing direct from the module insteadof from barrel file litegraph.ts. Using a different name helps avoid any confusion between two export files in future.

I think better name is LiteGraphInternal now, just pushed new commit for it : D

I'm still a bit confused - the imports should always work so long as you don't mess with the barrel file and import from it first. I balanced this a long while back, and messing with it is complex and frustrating to debug (especially with the ecosystem using the LiteGraph global var).

I just ran fix-verbatim-module-syntax npm package on another branch, and had CC convert the script to a vue version then ran it again. It all seems to be working fine.

PTAL: https://github.com/Comfy-Org/ComfyUI_frontend/compare/verbatim-module-syntax?expand=1

[webfiltered]

Argh ran the wrong tests. Okay, I see the error you saw. This is actually just an issue with the test files.

[webfiltered]

Yeah, can fix this easily by doing type imports properly:

import { type ThingToImport } from '@/file'

This still imports the file when running tests. We don't notice it in prod because it uses different systems (vite/bundle).

Should be:

import type { ThingToImport } from '@/file'

This type of import is only used for type information, pre-compile - doesn't exist at runtime.

[snomiao]

Argh ran the wrong tests. Okay, I see the error you saw. This is actually just an issue with the test files.

I think we can merge your solution as first step:

import { type ThingToImport } from '@/file'

and then gradually refactor in following PRs into:

import type { ThingToImport } from '@/file'

to make things work smoothy, WDYT? @webfiltered @DrJKL @christian-byrne

[webfiltered]

I think if we're going to do this change and touch all the imports, we may as well just do it all at once. I would not want to keep having to sanity check this repeatedly.

Pretty sure there's a linter that can auto-fix the imports. Failing that, we can just stuff the ast-grep I used into the pre-commit - it was very fast.

If there are more issues in future, it's just from direct importing. Runtime imports should be via the barrel, not direct importing from internal LiteGraph files.

[github-actions]

🔧 Auto-fixes Applied

This PR has been automatically updated to fix linting and formatting issues.

⚠️ Important: Your local branch is now behind. Run git pull before making additional changes to avoid conflicts.

Changes made:

• ESLint auto-fixes
• Prettier formatting

[snomiao]

Closed this as may not needed anymore since i18n locales workflow fixed by another approach #5775