SP_ListAny

A tiny utility node with one job: take up to five separate values - any type, any mix - and hand them back out as a single list. If you've ever wanted to feed several individually-generated things (a handful of strings, a few images, whatever) into a downstream node that expects one list input instead of several separate wires, this is the node that does that collapsing.

How it works

There are five optional inputs, value1 through value5, every one of them typed * - ComfyUI's wildcard type, meaning any output from any other node can plug into any of these slots. All five are optional, so you don't need to fill every slot; wire in the two or three you actually have and leave the rest empty. The single output, values, is marked as a list (is_list: true), which is what makes this useful: downstream nodes that expect to iterate over multiple items - a batch step, a "for each" style pattern, anything built around ComfyUI's list-handling - can take this one output instead of needing five separate connections managed by hand.

Because every slot is wildcard-typed, ComfyUI's normal type checking won't catch a mismatch here the way it would with a typed MODEL or IMAGE port. Plugging a STRING into value1 and a LATENT into value2 will connect without complaint; whether the resulting list makes sense depends entirely on what the downstream node does with mixed types, and that's on you to track, not on this node to prevent.

Inputs and outputs that matter

• value1–value5 (all optional, all type *) - whatever you want bundled; leave unused slots empty.
• Output: values - a list containing whichever slots you filled, in order.

How to install it

Through ComfyUI Manager: search "SP-Nodes," install, restart. Manually:

cd ComfyUI/custom_nodes
git clone https://github.com/bananasss00/ComfyUI-SP-Nodes

Restart ComfyUI afterward. No models, no dependencies - this is pure graph plumbing, nothing runs at inference time.

Common issues & troubleshooting

Downstream node errors on an unexpected type. Since none of the five slots are type-checked, it's easy to end up with a mixed-type list without noticing - trace back through which slot has what plugged in before assuming the downstream node itself is broken.

Empty slots show up as gaps or nulls in the output list. If a downstream node expects exactly N items and you've only filled some of the five slots, check whether it's iterating over five positions (some empty) or over however many you actually connected - that behavior isn't documented in the pack's README, so test with a small case before relying on it in a larger workflow.

Order in the output doesn't match what you expected. The list follows slot order (value1 first, value5 last) regardless of the order you wired things in the graph - if ordering matters downstream, wire deliberately by slot number rather than by whatever felt natural while building the graph.