Pico targets fail to build w/ ReferenceError

[ralphwetzel]

@phoddie -- Fortunately @rei-vilo ran his tests with a Raspberry Pi Pico W. All other Pico target fail to build (at least on my system) with

### ReferenceError: module "embedded:io/socket/tcp" not found!

despite I'm not using (for this test) any node that needs networking capabilities. I think, this is due to the fact that manifest_runtime.json, included by default, includes various other manifests that depend on the embedded socket/network code.

Simple test case:

[
    {
        "id": "d54ee83032ee8422",
        "type": "tab",
        "label": "Flow 10",
        "disabled": false,
        "info": "",
        "env": [],
        "_mcu": {
            "mcu": true
        }
    },
    {
        "id": "4311906cded2e5d5",
        "type": "inject",
        "z": "d54ee83032ee8422",
        "name": "",
        "props": [
            {
                "p": "payload"
            }
        ],
        "repeat": "",
        "crontab": "",
        "once": false,
        "onceDelay": "3",
        "topic": "",
        "payload": "",
        "payloadType": "date",
        "_mcu": {
            "mcu": true
        },
        "x": 360,
        "y": 360,
        "wires": [
            [
                "359cc37ba40d4b50"
            ]
        ]
    },
    {
        "id": "359cc37ba40d4b50",
        "type": "debug",
        "z": "d54ee83032ee8422",
        "name": "Debug from MCU",
        "active": true,
        "tosidebar": true,
        "console": false,
        "tostatus": true,
        "complete": "payload",
        "targetType": "msg",
        "statusVal": "payload",
        "statusType": "auto",
        "_mcu": {
            "mcu": true
        },
        "x": 550,
        "y": 360,
        "wires": []
    }
]

[phoddie]

True. We tend to assume a network (especially for Node-RED)!) But the original Pico doesn't have networking. Not immediately sure what the best solution is but will take a look.

[ralphwetzel]

@phoddie -- Did you find time to decide on a way forward for this issue? Couldn't we opt in the network related manifests (for Pico targets) based on a configuration item defined in the platform manifest?

[phoddie]

Sorry, no great solution yet. The correct solution is to break up manifest_io so that projects only include what they need. That's a big undertaking, so it hasn't happened yet.

Yes, you could probably workaround it by including the networking bits on devices that don't need them. I just hesitate to commit that for fear it stays that way for a long time.

[rei-vilo]

I would be perfectly fine with Moddable / Node-RED MCU requesting connectivity and supporting only boards with that feature. After all, Node-RED focuses on IoT.

So the Raspberry Pi Pico would not be supported, only the Raspberry Pi Pico W.

[phoddie]

Thanks, @rei-vilo. That's a good point. I do still think there are many interesting uses of Node-RED on devices without a network connection, so I'd like this to work eventually. It isn't really a technical limitation. There's just some untangling of the build system, which we want to do anyway to save space by excluding unused code in the firmware.

[rei-vilo]

An option could be to build all the libraries and ask the linker to ignore those not used.

[phoddie]

Unfortunately, it isn't that easy. That works for native code (and we take advantage of that often!). Once a native function is referenced by a script binding, the native linker (gcc, etc) can't strip it.

[ralphwetzel]

@phoddie: Great job! 👍 This works now as well on devices without networking capabilities!

[phoddie]

Excellent. Thank you for confirming. Much of the credit goes to @mkellner.