Is the Packaging Subflow Modules Documentation Obsolete or needs update?

General
1

I am not sure but packing the the respective nodes into flow array as mentioned in the Documentation for node-red v2.2 doesn't work when packaging the subflow as a module.

JSON Generated during Export

The documentation Packaging a Subflow as a module : Node-RED suggests that the Exported JSON takes the form of

[
   { "id": "Node 1", ... },
   { "id": "Node 2", ... },
   ...
   { "id": "Node n", ... },
   { "id": "Subflow Definition Node", ... },
   { "id": "Subflow Instance Node", ... }
]

For version 2.2.2 this is quite the contrary since the structure is generally

[
    {
        "id": "f40ab2fe576b55f7",
        "type": "subflow",
        "name": "..",
        "info": "..",
        "category": "",
        "in": [
            {
                "x": 480,
                "y": 140,
                "wires": [
                    {
                        "id": "f06facfb30103d6c"
                    }
                ]
            }
        ],
        "out": [
            {
                "x": 940,
                "y": 140,
                "wires": [
                    {
                        "id": "f06facfb30103d6c",
                        "port": 0
                    }
                ]
            }
        ],
        "env": [],
        "meta": {},
        "color": "#C0DEED",
        "icon": "node-red/bridge.svg"
    },
    {
        "id": "f06facfb30103d6c",
        "type": "mqtt in",
        "z": "f40ab2fe576b55f7",
        "name": "Internal MQTT Broker",
        "topic": "",
        "qos": "2",
        "datatype": "auto",
        "broker": "b5bc2cca74215822",
        "nl": false,
        "rap": true,
        "rh": 0,
        "inputs": 1,
        "x": 700,
        "y": 140,
        "wires": [
            []
        ]
    },
    {
        "id": "b5bc2cca74215822",
        "type": "mqtt-broker",
        "z": "f40ab2fe576b55f7",
        "name": "Internal MQTT Broker",
        "broker": "internal-mqtt-broker",
        "port": "1883",
        "clientid": "node-red-mqtt-internal-in",
        "autoConnect": true,
        "usetls": false,
        "protocolVersion": "4",
        "keepalive": "60",
        "cleansession": true,
        "birthTopic": "",
        "birthQos": "0",
        "birthPayload": "",
        "birthMsg": {},
        "closeTopic": "",
        "closeQos": "0",
        "closePayload": "",
        "closeMsg": {},
        "willTopic": "",
        "willQos": "0",
        "willPayload": "",
        "willMsg": {},
        "sessionExpiry": ""
    }
]

Even upon packing the dedicated nodes under flow array (as mentioned in the documentation) provides errorenous node (mostly under the function palette.

Tests

  • running two instances of nodered/node-red:2.2.2 with different published ports e.g. 1880 and 1990
  • create a simple subflow with MQTT In and export the subflow JSON to the clipboard.
  • Paste the same JSON into the other instance of Node-Red and the node is available readily without having to change the export values
2

Without knowing exactly what you have done to package your subflow it's hard to say what is happening.

The process of converting the JSON exported by the editor into the right format to package into a module is a little cumbersome. The intention was always to create some tooling to help with that... but it hasn't happened.

It is true to say when exporting a subflow instance from the editor, the JSON does have the definition node at the start and not the end - so yes, the docs need updating to reflect that.

[
   { "id": "Subflow Definition Node", ... },
   { "id": "Node 1", ... },
   { "id": "Node 2", ... },
   ...
   { "id": "Node n", ... },
   { "id": "Subflow Instance Node", ... }
]

But that point aside, following the instructions in the docs should still work. If it is failing for you, then please provide an example subflow module you have created so we can look at what you've done.

3

@knolleary Thanks for reaching out I am currently documenting the potential workflow In the following

I am just about to put an update to what the status is and what the workaround currently is.

4

As you already have a thread open on this topic, I'll close this one and we can focus discussion in one place.