Use engines in package.json to determine the node-red version requirements for custom nodes

Core Development Feature Requests
1

vscode, npm, pnpm, yarn use engines to determine their minimum required version. Node-RED could do the same to make the ecosystem of packages authored using a package.json to describe its metadata consistent.

2

Node-RED does use engines doesn't it?

Each version is pegged to a specific version of node.js which is the minimum version people should be using.

    "engines": {
        "node": ">=18.5"
    }
}
3

Does it read engines.node-red to verify if a package is compatible with a given node-red version?

{
    "engines" : { 
        "node-red" : ">=4"
    }
}

I thought node-red would only read node-red.version from the package.json to verify if a package is compatible.

Like npm, yarn, pnpm and node, vscode also reads engines.vscode to determine if an extension is compatible or not, instead of a separate vscode attribute in the package.json.

4

Ah, I see what you mean.

No, but each node package is supposed to specify what versions of Node-RED it is compatible with. e.g. from UIBUILDER 7.x:

image
image546Ă—512 12.7 KB

So that is how it checks whether a node is compatible I believe.

PS: Think I mangled understanding what you wrote there - still, hopefully clear.

5

Yes, I think that is the only way at the moment. But to standardize the ecosystem, Node-RED should also read the value from the engines.node-red property in package.json

6

npm, pnpm and yarn are all general package managers.

Other than VS Code, are you aware of any other applications that make use of engines for their own app version checks?

Not saying that using engines wouldn't have been a better choice. However, it has been that way for a long time now - is it sufficiently critical to want to disrupt it?

7

Electron apps also use it

1 Like
8

It is my ocd, really. I like to follow standards when I notice them

9

Oh, I get it - I have the same "issue" :slight_smile:

However, I also have a lifetime of IT experience as well. Sometimes, things have to be put into priority. :person_shrugging:

There are so many exciting things that could be done still with Node-RED and so few people to work on them. Just my personal opinion, but we have something that works and is clear and easy to use, robust and reliable. Might not be perfect but it works. Changing at this point would take up valuable development and testing resources and might result in additional confusion.

1 Like
10

I completely forgot I created this request:

1 Like