Developing on fork of node

I plan to develop features on a contrib-node, and make a PR (my first with real code!) to the original project on GitHub.

What is the best way to do this ?

Should I change the package.json to point to my fork during development? Although it won't be published as a npm?

Should I reassign git origin of node_module to my fork ?

Any smart ways or recipes ?

The easiest way I've found is to firstly stop node-RED and remove the node that you want to work on from your node-RED palette via the cli npm remove <npm-package-name>.

Then git clone the contrib node that you want to develop, and follow this guide to add your local 'git' version of the node back to your palette via a symlink.

You can then start node-RED, and make whatever changes you wish to the local 'git' repo.
When you are happy that it works as it should, you can then create a git pull request.

Thanks. Hadn't thought of removing the original first. I guess I was afraid of difficulties when the flows wouldn't find the node used all over, but of course it won't get started back up before the "imposter" is linked back in the position:)

Yes, thats what I do anyway. I'm pretty sure someone will come along shortly and tell me I've been doing it wrong :grin: :grin: :grin:

In addition it is a good idea to do the development on a branch rather than on master. That way it is easier to identify what you have done.

Yes, I believe they merge PRs to dev branch, so that is my starting point, but I then branch to "feature/[..description..]" and code there.

Thanks both @Paul-Reed and @dceejay. I just think I saw a recipe some time where "npm link" was used extensively. No need then.

Any thoughts on me coding this in VSCode on the mac with the Remote extension so I actually develop this on my raspberry pi ? I have to live test the node with the devices connected only to the pi. Ok ? I should just as easily be able to revert catastrophies there.

Someone who knows more than me told me to fork and then make a new branch in your fork and make the changes in that.

Then, when making a pull-request - you do it from your new branch - it keeps things cleaner I was told

While developing, I recommend just working on the node files in an alternate install from @TotallyInformation

Once I'm happy with changes - I then just copy/paste from local files into the github branch created earlier

I don't use VSCode but I use Notepad++ in this manner to do the editing so it should work

1 Like

Thanks for the input from experience!

I would like to try to get more familiar with git in the process and be as "pro" as is possible, so I would have thought I could "checkout" the master branch again when pausing development (instead of switching between node-red installations) ? Even from the node-red GUI I believe ?

1 Like

Well there's your suggested method and my KISS one :slight_smile:

Choose wisely Padawan :slight_smile:

In seriousness - mine works well if its just changing the .js file and can cope if its the .html file as well - once the changes get more complex than that - then prob full on git starts to be worth it

I'm practically sure I will accidentally kill an Ewok or two here, but until then I have my mind set on the learning part of all this :slight_smile: I did take note of your way though.

1 Like

Actually, the branch switching inside the node-RED GUI is related to my flows/project of course, and to make that switching work in this case I would have to have two different package.json files, keep the original node in place on my project's master branch, and also restart all of node-red when switching.... ? Maybe that's a step too far for me, or did I just confuse myself again ?

all I heard was something about kilts ......... :slight_smile:

1 Like

Well ... :rofl:

You don't need to do that any more. You can simply do an npm install against a folder name and npm will work it all out for you. In your package.json it will use a file: reference.

Me too :grinning:

Especially if you need different configurations to test. For example, using httpRoot, projects, etc.

I’m only experimenting with code in this particular node for now.

And when finished (accepted PR, etc) I just npm install the original node from npm over it again?

Maybe it's not necessary, but I usually remove the 'git' version before installing the original node.

Stop node-RED
npm uninstall ~/dev/node-red-contrib-example-node - (path to your project)
npm install <npm-package-name> - install original
Start node-RED

3 Likes

I really appreciate it getting all new necessary knowledge (To contribute!) from this helpful community!

I’m too wary, or just too ahead of myself here, but if you would still indulge on my first mini-coding-project:

“Npm install ” links “node_modules” to my node code, so I will only have to restart node-red to test a new iteration? Or will I have to increase a fictive version number too and reinstall it every time?

If it is local just stop and restart. No re-install or version number change necessary.

3 Likes