Sharing config nodes between separate packages

Developing Nodes
1

Hello,

I recently decided to separate one of my node-red-contrib packages into two packages. I did this because some of the nodes were becoming redundant but offered a simpler method of usage.

My problem is that they both use the same config node to store an external API key and I would like for it to remain generic & common.

First attempt - wishful thinking

I tried adding the following checks before registering the node in both the .js and .html files but I was still getting warnings about an already registered node

if(!RED.nodes.registry.getNodeType("alpaca-config")){
    RED.nodes.registerType('alpaca-config',{
//-----------------------node definition here
    });
}
if(!RED.nodes.getType("alpaca-config")){
    RED.nodes.registerType('alpaca-config',{
//-----------------------node definition here
    });
}

I think it was the fact that "alpaca-config" was still defined in my package.json so I gave up on this approach.

Current solution - copy the dashboard nodes...

I realized this is a similar situation to the dashboard nodes, how there are separate packages that share the same group and tab nodes. Looking in there it seems that the "ui_group" is specified in node-red-dashboard and that all the peripheral packages call up ui_group from this package.

This is the approach I have taken and it works, but I would really like for a user to be able to pick one or the other package instead of requiring the primary package to be installed.

Possible solution - will this work?

I got to thinking, that maybe this problem can be solved with NPM. What if I separate out this configuration node into yet a third package and make it a dependency of both of my user-level packages, this should be a viable solution right? I guess my only question is will I need to register this config-level node with nodered.org or just publish it to npmjs? I see that nodered no longer automatically registers packages with the node-red tag so perhaps this is a use-case for that middle ground?

I know I could just try it out and see but I wanted to get some thoughts as I'm really out on a limb at this point.

Thanks for your time,
-Matt

2

Hi Matthew,
We had a discussion last week (see here) which might give you some ideas, because it was also about code sharing.

It is not clear to me why that code snippet doesn't work. At first sight it seems a reasonable good idea to me. Would be nice if somebody could enlighten the both of us...

Bart

3

I took a second look at my first approach just to make sure I wasn't dizzy and missed something. Same result, only way to get no conflict warnings is to remove the config.js from package.json.

Even more confusing is I put an else{ console.log("-----skipping config node"); } on the end of my check (plus one at the beginning of the .js) and I get no message in the node console or in my browser console. I'm definitely missing something. (edit: I even tried changing the index name of the .js in my package.json to "something-else":"config.js" and it still clashes)

Looks like you folks in the linked thread are discussing a use-case far more complicated than what I'm trying to do which has inspired me to go for it. I'm going to separate my config node into a dependency and I'll report back how it goes :slight_smile:

1 Like
4

Well, there were some growing pains, but the separate package option works!

One growing pain I experienced was I originally thought to rename the node to something else when separating it out but this caused all my flows to break!

My thought was that if someone had "mismatched" versions of the sibling projects they would get the same clash I was trying to avoid but I don't think that is the worse issue.

Thanks for the input!
-Matt

1 Like
5

For posterity, one other thing I noticed is that apparently npm install doesn't install dependencies if using a local file location (ie. "npm install ~/environment/node-red-contrib-..." . I had to upload everything to github first and then it worked as expected.

6

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.