I'm currently on a project that use lots of Firebase capabilities (store, auth, admin, ...). As I'd like to use specific nodes for each action (not a big fan of the 'One to rules them all' node), I try to use focused contrib nodes.
The problem is each one redefine a Firebase admin node, leading to conflicts. So here's the question: what the best strategy for that?
My first guest is to have a node-contrib-firebase-admin that would be a dependency of all the modules but I don't know if this will work and/or be an acceptable solution.
The recommended way is to use a config node - for example see the mqtt nodes or serialport nodes. The config node is the common part that usually creates and manages the connection - then the other nodes can call or listen to that as appropriate.
Yes, the config node exists. But how can we 'share' a config node between multiple contrib? Blindly requesting this node in the init might result in weird error for the user.
And how could the install be streamlined so you won't have a runtime error because the config node has not been installed with the firebase node?
Thanks, but if multiple nodes reference it as a dependencies, wouldn't it create a conflict? What about peer dependencies? That won't install it automatically (since npm3) but would be able to play nice with each other, and allow some version flexibility.
(ah the joy of npm dependencies)... if they use the same version then no problem as it will install just one version - but that mean keeping yourself in sync with the other node. - if they specify different then they will install their particular version under their node_modules tree.
peer dependencies does play nicer - but as you point out won't force it to be installed if not already present - it will just warn at install time. So your node would have to check it is installed and warn the Node-RED user at run time if it's not there. Indeed that would be my preference - but it's your node.
I'll try peers, that looks like the cleanest solution. If I remember correctly NPM will print a warning at installation if the peer dep is not resolved.
I'll make a small test and write here my conclusion!
yes it will print a warning - but if the user uses the palette manager to install they will never see that - unless they actually do look at the logs... and then your node won't work... so you need to handle the case when it isn't installed gracefully via a warning etc
