_.all
Does every element in your list pass the test?
- obj
- BOOLEAN
_.all is the Underscore.js all method wrapped up as a ComfyUI node: feed it a collection, provide a predicate truth test, and it returns true only if every element passes. The moment one element fails, it short-circuits and stops - no wasted iteration over the rest of the list.
This is part of the comfy-ovum pack's experiment in porting Underscore.js (via the underscore3 Python port) into the graph. The collection methods are all here - map, filter, reduce, and the boolean checks like this one. The node's own description spells out the semantics: "Returns true if all of the values in the list pass the predicate truth test. Short-circuits and stops traversing the list if a false element is found."
When you'd reach for it
Validation and gating. You have a list of values and you want to know if everything meets some condition before a branch proceeds - all seeds within range, all paths exist, all scores above a threshold, all items non-empty. A true out of _.all is a clean signal you can feed straight into an IfElse or conditional node.
How it works
The node wraps your input in an Underscore chain (_ensure_us deep-copies the object so nothing mutates), calls the all method, and returns the boolean result. The predicate is "transformed through iteratee to facilitate shorthand syntaxes" - Underscore's shorthand trick, where a string can stand for a property name or a small object can stand for a match test, so you can express simple predicates without writing a function.
The primary input is obj (optional, *): your list, dict, or any collection. It also accepts a _.CHAIN object so you can pipe this node mid-chain - feed it the chain output from another underscore node and it continues the pipeline. Output is a single BOOLEAN.
The catch you need to hear
The pack's own README is blunt: the underscore nodes are "an absolute disaster to use in production. They are a WORK IN PROGRESS and are not recommended for use in workflows." That's the author talking, not me editorializing. The mechanics exist and work for simple cases, but the predicate wiring - especially providing iteratee functions through the UI - is fiddly, and the whole subsystem carries a WIP flag. For a one-off check in a throwaway workflow, fine. For something you'll rely on, expect to maintain it.
Installing it
Part of the comfy-ovum pack:
cd ComfyUI/custom_nodes
git clone https://github.com/sfinktah/comfy-ovum
Restart ComfyUI, or ComfyUI Manager → search "comfy-ovum" → Install. The underscore port is bundled in the pack, no extra downloads.
Common gotchas
- The predicate is the fiddly part. Simple shorthand predicates (property names, JSON match objects) work; complex function predicates via the UI are where the WIP shows.
- It short-circuits, so order matters. If the first element fails, later elements are never tested. Usually irrelevant; occasionally surprising when you're hunting a bug.
- Boolean outputs feed logic nodes, not much else. You're generally wiring this into an IfElse-style branch or a debug display, not onward data processing.
Inputs (1)
| Name | Type | Default | Description |
|---|---|---|---|
| objopt | * | Primary input object. Also accepts _.CHAIN to continue chaining. |
Outputs (1)
| Name | Type | Description |
|---|---|---|
| BOOLEAN | BOOLEAN | — |