JavaScript_clh
Run actual JS inside your workflow
- codeMirror
- codeStr1
When ComfyUI's built-in nodes can't do the little bit of logic you need - reformat a string, build a JSON payload, branch on a value, do some string surgery a prompt node can't - this node lets you just write the code. It gives you a code editor, you type JavaScript, and it returns whatever your code returns as a string. For the rare moment when you need real programming inside a graph that's otherwise all boxes and wires, it's a hatch.
That's also the reason to be a little careful with it, which we'll get to.
How it works
The input widget is a proper code editor (the schema calls its type CLHCODE, and it's backed by a CodeMirror editor, so you get a real multi-line box with code formatting rather than a cramped text field). You write a snippet, return a value at the end, and that value comes out the other side as a string. The default snippet - console.log("Hello world"); return "{}"; - tells you the shape: do some work, log if you want, return a string.
Because it returns a string, the natural pairing is with the pack's other nodes: build a JSON string here and feed it into an EchartOptionByPath clh to chart it, or construct a prompt fragment and pass it into your conditioning. It's glue for the cases where the declarative node graph runs out of expressiveness.
This is the same itch rgthree's Power Puter scratches - a compute-arbitrary-logic-mid-graph node - but a different tool. Power Puter runs Python-like expressions parsed to an AST against an allowlist of safe built-ins, deliberately so that open, network calls, and imports aren't reachable. The clh node runs JavaScript and hands you the result. That's more freedom and, correspondingly, more rope.
The inputs and outputs that matter
codeMirror(required, the code editor) - your JavaScript. Write it, make sure itreturns something, done. This is the entire node.
Output is codeStr1, a STRING - whatever your code returned. It's also an output node, so it runs and shows its result even with nothing wired after it, which makes it easy to test a snippet in isolation before you plug it into anything.
Installing it
ComfyUI Manager: search Clh Tool for ComfyUI, install, restart. Or by hand:
cd ComfyUI/custom_nodes
git clone https://github.com/clhui/ComfyUi-clh-Tool
then restart ComfyUI. A node that executes JavaScript almost certainly leans on a runtime or library to do it, so if you install by hand and the node doesn't appear, read the ComfyUI startup console and pip install whatever import it's complaining about - Manager runs that dependency step for you, a bare git clone doesn't.
Common issues
The obvious one: your JS has to actually return a string. Forget the return, or return something that doesn't serialize cleanly, and downstream nodes get nothing useful. When in doubt, return JSON.stringify(yourThing).
The one worth taking seriously is security. This node runs code. Anything that runs code from a workflow file is a thing to respect - if you load someone else's workflow that contains a JavaScript clh node, you're potentially running their code on your machine. The KB's read on ComfyUI custom nodes generally is that Manager can install a node but can't verify it's safe, and an arbitrary-code node is the sharp end of exactly that. Read the snippet before you hit run on a workflow you didn't build. For most in-graph logic, honestly, a purpose-built node or rgthree's sandboxed Power Puter is the calmer choice; reach for raw JavaScript when you specifically need it and you trust what's in the box.
Inputs (1)
| Name | Type | Default | Description |
|---|---|---|---|
| codeMirror | CLHCODE | console.log("Hello world!"); return "{}"; | — |
Outputs (1)
| Name | Type | Description |
|---|---|---|
| codeStr1 | STRING | — |