That's a brilliant idea, I am adding it to the next release, it's not much work to implement
it will be behind a --wrap parameter, it allows integration with code based testing tools like vitest for all your functions. I personally use a different approach, but i can see how useful it could be. It wont effect vue templates, only basic functions.
I should have a new working version soon, maybe later on today
1 Like
I have fixed the issue with version 1.0.3, it was a problem with chokidar setup.
I have improved the readme, to explain better how to get started. I will also try to make a short video of how to set it up and how it works.
2 Likes
video is up on youtube to explain how it works
3 Likes
Perfect! 
With vers.1.0.4 it's doing the job.
And video is a great bonus 
Thanks @daniel-payne for creating this tool. Sadly, family commitments have kept me from trying it yet. But as I typically always have open at least 3 or 4 VS Code workspaces, and as I do tend to use function nodes to simplify flows, I am certainly going to give this a go.
@ daniel-payne
The functions-templates-manager helps a lot when editing functions and ui-templates from the outside. Once again GREAT work!
Here's an additional idea/request, hoping you have time and see another benefit.
It's about the documentation of nodes/flows. I haven't found a good solution so far.
Both node types (function, ui-template) offer the possibility of an info page. In Node-Red these can be edited with markdown functions, and that is a bit difficult / cumbersome.
If the functions-templates-manager would also export/import the info parts of the nodes, the documentation could be much easier by using appropriate tools
Any thoughts?
What about VS Code makes it easier than vs. Node-RED? I have my own opinions on this, but curious to have the conversation about what Node-RED could be doing differently.
1 Like
node-red is brilliant, been using it for years as my go to ETL. I have written a couple of articles extolling its advantages. I wanted to introduce it as the main processing of customer information at a bank, but coming up against the cooperate inertia of Microsoft's power-apps. To be honest I think power-aps are the next silverlight, and it's going to get doped when some cooperate alignment changes.
But lately wanted to use it in financial data processing, options pricing requires some crazy maths functions in the processing flow. There is this Pareto rule 80/20, the first bit is easy, but the last bit takes all the effort/cost and gives you the competitive advantage. The node system of node-red gets me to 80% of my target very quickly. But I need to implement a yang-zhang volatility calculator and a black-scholes options pricer, we don't have nodes for them. The functions are long and complicated, it's not easy to compare them in the code editor. The video i posted shows the problem i faced. I tried opening two tabs to node-red, it worked for me. However I found I was missing the tools i am used to in VS-Code for working with functions, like copilot.
Also in the comments above, someone asked for this so they could use their normal testing tools with functions. These scripts allowed this. I do my testing differently and post results in the node.status() so i have a visual overview. I also see you are looking at a third approach for testing.
I tried to illustrate the problem I had and the solution i came up with in the video.
It started out as a hack for just me, but when i experienced the benefits i found, I tidied it up a bit and shared it here.
I have a small update coming, where when you delete a function in node-red it removes it from the /src. Also I will implement the suggestion above so there is a companion md file for the documentation.
The key to this, I think, is allowing hi-code developers who use node-red access to their standard way of coding. The synergy would be good.
I think node-red has a good future
For me, what is missing is a good integration with LangChain, but that's a massive job, way above my pay grade 
However with that you can compete and outshine n8n. Currently I use Flowise for my visual programming of Langchain.
- You can set your own ESLINT config.
- You can add your own custom "global" object definitions - e.g. things you've made available to function nodes that Node-RED itself does not.
- You can have multiple windows open - more specifically, you can have multiple function node windows open - this one is pretty big.
- You can use GitHub Copilot.
- You can use your favourite extensions.
There may be more but I need to do some paying work. 
1 Like
It isn't just about corporate inertia. It is about proven technologies backed by "trusted" vendors.
Selling an open source tool with minimal vendor backing is always a hard-sell, especially in controlled industries like banking and health (and yes I've worked extensively in both).
For example, where are the certified cyber audits of Node-RED services? How can Node-RED be audited, how can it be managed at a corporate level?
None of these things are insurmountable - but they can be hard, especially for organisations already working at max capacity.
It becomes much easier to get someone like Microsoft with proven, world-class cyber security and operational support to provide solutions even where they aren't as good.
Really, these should not be in function nodes - except for prototyping. No financial institution should accept financial processing through something like function nodes without significant controls wrapped around it. They should be in bespoke modules with controlled source code management.
In most banks, these calculations are in massive legacy Java pricing bots (and are slow), most started life over 20 years ago. This was a MVP to demonstrate what could be done, ie real-time options pricing and decision making, (my equations are years behind the curve, a quant would laugh at my school-boy calcs). But I have switched banks since then, and keep this going as a personal project, it has been written many times using different tech including nextjs and observableHQ.
However all of them were missing something i found when writing it in node-red. Visual representation of data flow, and logic flow & dependencies could be visualized. I have not had this kind of tool since classy (a delphi tool) in the 1990s.
This script concept i developed allows us to work just like we would normally. Version controlled and tested. My project is in a repo, just like normal banking projects. I don't use the --clean option, and commit the /scr directory.
https://github.com/daniel-payne/signalanalizer-nodered/tree/main/src/STARTUP
That's another advantage of using the /src directory, in something like gitLab, code review comments work well and it can be tied into a JIRA system. It's difficult to manage the flows.json in normal gitLab style devops code reviews.
O how I love devops and corporate programming, but it pays the bills
2 Likes
Please excuse some of the finer details (paddings, colours, etc), but just wanted to put the structure in place to communicate an idea based on the above.... why couldn't Node-RED have a "Flow Mode" and a "Code Mode" (toggle in top-right)
You can still edit the functions exactly as now in "Flow Mode", but when switching to "Code Mode", the left side lists all functions, templates, (someway of third-party nodes being able to define that they can live here too?). Would then be possible to integrate coding assistants, covers the multiple files open at once challenge, and prevents the need to keep switching between multiple pieces of software.
I can put a separate post for this into "Core Development" to open a new thread too, which would make more sense I think
That would certainly be a step forwards. However, it still wouldn't deliver on all of the things I mentioned. There is also a question in my mind about whether it is wise to build something into Node-RED that provides maybe a 50% solution where an integration with VS Code would provide 100%.
How about for those that don't use VS Code though? Not everyone uses it, and users for VS Code are reducing with the introduction of Cursor, Claude Code. We have team members using JetBrains IDE instead too
Yes, I understand that. It isn't that your idea isn't interesting & useful, I'm just pointing out that it still isn't a complete solution.
The ability to use an external editor is a really interesting and flexible idea. It wouldn't need to be tied to a specific IDE, most will support interfacing in a relatively standard way such as through URI's.
1 Like
I thought about this, I looked at writing a VS code extension to unpack the flows.json file.
It was a big job (as compared to the scripts), and I think it might take a bit of development effort in node-red IDE. Code Mode would be a good step for intermediate between low-code and hi-code development.
However you won't have the ability for the kind of corporate devops, where code reviews are needed for each change, ie each line is reviewed and potentially commented on. I know this is not the main target audience of node red. Also in this corporate world, they require tools running for unit test code coverage. My current project has 100%, ie every line is covered by a test. I can't raise a merge request until these tests pass. Also on other projects, a member of the QA team, will write a lot of unit/integration tests covering the code.
In addition the scripts would allow other IDEs to interact with the code. It's not really useful to a low-code project that uses standard modules, but it easily (and cheaply from a development perspective) extends the abilities when venturing into more complex processing.
Maybe the scripts could be merged into the node-red runner, behind a flag and started in another process so as not to interfere with performance. Before that, it would be good build unit tests on the scripts and have a few people use it for a while without errors. Plus, there would need to be some good documentation explaining this to people who come from a low code environment, who have not had the joy of hard-core devops. As two places for a line of code could be confusing.
Having a single flows.json is a major plus for node-red, as it allows for easy distribution of projects. I would not want to break that. So that's why i thought of the /src folder.
BTW version 1.0.5 is on github, and you won't need the --clean instruction, as the scripts will remove any files from /src when they are not present in the flows.json file.
2 Likes
That's where FlowFuse comes in.
But just like not everyone uses VS Code, not everyone uses FlowFuse. 
And, of course, in many corporate environments, especially in controlled industries, it might never be possible to use FlowFuse for a variety of reasons.
