Node Extension Builder Advanced
The expert metadata sidecar
- advanced_options_json
- summary_json
Keep the boring-but-important stuff off the main node
The extension-builder trio in MKRShift_Nodes has a sensible division of labor. MKRNodeExtensionBuilderPlan handles the core identity (name, publisher, version, node list). MKRNodeExtensionBuilderAdvanced is the sidecar that carries everything else - the metadata that makes a published node pack actually professional: description, repository URL, license, tags, web directory, min ComfyUI version, and optional extras.
Why split it? The README says it plainly: "For cleaner graphs, keep expert metadata on MKRNodeExtensionBuilderAdvanced." If every builder workflow had a dozen text fields sprawled across the main node, your graph would be unreadable. This node collects the noise, emits one tidy JSON object, and you wire that into the Plan node.
The inputs
All required, though most have sane defaults:
description- the pack's description, pulled into the manifest and later the pyproject.repository- the GitHub (or other) URL, used to derive the project URLs.license_name(defaultMIT) - the license identifier.web_directory- yourweb/folder for custom frontend extensions, if any.min_comfyui_version- the minimum ComfyUI version your nodes need.tags_csv(defaultcomfyui, mkrshift) - comma-separated tags for the registry.extras_json- an expert-only JSON object merged into the manifest'sextraspayload (per the tooltip). For things like custom fields, workflow example dirs, or anything non-standard.skill_url- if your build flow depends on a specific builder skill/CLI.builder_cli_command- override the default builder CLI command with your own.
For a beginner shipping a first pack: fill in description, repository, and license_name, leave the rest alone, and you're already ahead of most packs on the registry.
The outputs
advanced_options_json- the structured bundle, ready forMKRNodeExtensionBuilderPlan.advanced_bundle_json. The summary tells you the next step in its ownnext_stepfield, which is a nice touch for a tool you don't use daily.summary_json- which keys got set, how many tags, whether extras are present, and warnings.
Install and the intended flow
cd ComfyUI/custom_nodes
git clone https://github.com/criskb/MKRShift_Nodes
Restart, or install "MKRShift Nodes" via ComfyUI Manager. No pip deps, no models, no ffmpeg.
The intended chain, end to end: MKRNodeExtensionBuilderAdvanced → advanced_options_json → MKRNodeExtensionBuilderPlan.advanced_bundle_json → builder_manifest_json → write to extension.builder.json → run your builder CLI. There's an example workflow in the repo (example_workflows/mkrshift_extension_builder_plan.json) that wires exactly this. One honest note: this is a niche, developer-facing node in a brand-new pack - expect rough edges and check the summary's warnings output when a run looks wrong. It's plumbing, but plumbing that can save you a whole evening of hand-writing pyproject boilerplate.
Inputs (9)
| Name | Type | Default | Description |
|---|---|---|---|
| description | STRING | — | |
| repository | STRING | — | |
| license_name | STRING | MIT | — |
| web_directory | STRING | — | |
| min_comfyui_version | STRING | — | |
| tags_csv | STRING | comfyui, mkrshift | — |
| extras_json | STRING | {} | Optional expert-only extras object merged into the manifest extras payload. |
| skill_url | STRING | — | |
| builder_cli_command | STRING | — |
Outputs (2)
| Name | Type | Description |
|---|---|---|
| advanced_options_json | STRING | — |
| summary_json | STRING | — |