# Defining utility functions for re-use in a function node **URL:** https://discourse.nodered.org/t/defining-utility-functions-for-re-use-in-a-function-node/100294 **Category:** Feature Requests **Created:** [1 February 2026 19:21 UTC](https://discourse.nodered.org/t/defining-utility-functions-for-re-use-in-a-function-node/100294 "2026-02-01T19:21:17Z") **Posts on this page:** 18 **Page:** 1
### Author: ![Steve-Mcl](https://sea2.discourse-cdn.com/flex026/user_avatar/discourse.nodered.org/steve-mcl/32/4826_2.png) [@Steve-Mcl](https://discourse.nodered.org/u/Steve-Mcl) #### Post date: [1 February 2026 19:21 UTC](https://discourse.nodered.org/t/defining-utility-functions-for-re-use-in-a-function-node/100294/1 "2026-02-01T19:21:17Z")
Hi all, I am well aware there are a lot of threads that ask a variation of "How can I write a utility function and call it from other functions. e.g: - [RED.library.register usage](https://discourse.nodered.org/t/red-library-register-usage/1175) - [How to create utility function in node red](https://discourse.nodered.org/t/how-to-create-utility-function-in-node-red/33014) - [Defining and reuse a "classic" JS function](https://discourse.nodered.org/t/defining-and-reuse-a-classic-js-function/16372) - there are many many more. I have had some ideas floating around for some time (I've even written code for some of them) but I've always felt they lack _a certain something I dont know what_! Today felt like a good day to explore some solutions (old and new) I would appreciate your feedback / thoughts. Please note: There are many ways this could be approached and a ton of ways it could be better, but in the spirit of achieving the "re-usable" aspect and limited time (for NR 5), please try to stay on topic πŸ˜ƒ * * * ### Function Node - ideas and thoughts around shared function definitions #### Story As a Node-RED user, I want to define reusable logic that can be reused across multiple function nodes, so that I can avoid code duplication and maintain consistency. Implementing a way to define global functions would streamline this process and enhance code maintainability. Typically we suggest the user does this visually via link and link-call nodes (creating a subroutine), or by adding their functions to global context in a function node's on-start script or by adding code to the users settings.js file. However these approaches have limitations in terms of practicality/usability (if I am in a function, I typically want to stay in the function), maintainability (logic defined in a file or a random function somewhere not obvious is not ideal), reusability, and FBP familiarity / visibility. #### Implementation Ideas 1. Create a new configuration node type for global functions, allowing users to define and manage them in a centralized location. 2. Modify the Function node to permit registration and usage of these global functions. 3. Add a `RED.functions` (or similar) API to facilitate the registration and calling of global functions. 4. A `RED.util.linkcall` (or similar) API to facilitate calling link-inβ†’logicβ†’link-return subroutines programmatically from within function nodes. #### 1 - new configuration node type - Users can create a "Global Function" config node where they can define functions. - Function nodes can reference these global functions by name. ##### Pro - Centralized management of these utility functions. - Possibility of presenting the callable with typedoc defs (intellisense) ##### Con - Somewhat additional complexity in managing config nodes - New node type to create - Not backwards compatible - Chance of name collisions of function definitions? #### 2 - Modify Function node Extend the Function node's setup to allow users to make the function node a place where a global function can be defined (e.g.: **Function Scope "Normal" / "Global"** ) ##### Pro - Easy to use (familiar node-edit panel) - Visual - Could be backwards compatible (if we save the config of the node in the flow as if it were a standard function node and utilise the on-start function to register the functions in `global` context - anyone loading an old flow would see a disconnected function with some onstart code adding a utility function to global context) ##### Con - Mode based UI to show/hide parts of the function node - Disconnected / isolated function nodes feel odd. - Only function nodes can be used #### 3 - `RED.functions` API Introduce a new API within Node-RED (e.g., `RED.functions`) that allows users to register global functions programmatically. Something like `RED.functions.register('myFunction', typedoc)` then other functions can call `RED.functions.myfunction` ##### Pro - No need to modify existing nodes or introduce new config type. - Slightly simpler implementation. - Could potentially provide function node type hints (intellisense) ##### Con - Less user-friendly for non-developers - but then users requesting this kind of functionality are typically not beginners! - not visual - not backwards compatible (though a patch plugin might be possible to add this for older Node-RED versions) #### 4 - `RED.util.linkcall` API - Introduce a new API within Node-RED (e.g., `RED.util.linkcall`) that allows users to call visually defined subroutines from a function node. ##### Pro - No need to modify existing nodes or introduce new config type. - Simpler implementation. - leverages existing link-call nodes for reusability - benefits from visual aspect of link-call nodes - benefits from supporting more than just functions (core and contrib nodes can become re-usable logic too) - this was a surprising (but ultimately obvious) benefit! ##### Con - Less user-friendly for non-developers - but then users requesting this kind of functionality are typically not beginners! - not backwards compatible however a patch release on 4.x stream would be relatively simple. - failure mode mode in NR \<=3.x would be a regular node error complaining about `RED.util.linkcall` being undefined (or similar) #### Decision Matrix πŸ˜€=5=best/easiest ☺=4=good/not too difficult, 😐=3=neutral, πŸ™=2=worse/hard 😭=1=complex/worst/poor | Approach | Implementation | User Friendliness | Maintainability | Backwards Compatibility | Visual Aspect | Benefits | Score | | --- | --- | --- | --- | --- | --- | --- | --- | | 1 - New Config Node | 😭 | 😐 | 😐 | πŸ™ | 😐 | 😐 | 15 | | 2 - Modify Function Node | πŸ™ | ☺ | ☺ | ☺ | ☺ | 😐 | 21 | | 3 - RED.functions API | ☺ | 😐 | ☺ | 😐 | 😐 | 😐 | 20 | | 4 - RED.util.linkcall API | πŸ˜€ | 😐 | ☺ | 😐 | ☺ | πŸ˜€ | 24 | * * * So, based on the result of thatβ€‹πŸ‘†, I did a POC. And, you know what - I dont hate it! I thought I would, but no, it just works ℒ️and I havent had an _ah but_ moment either - which leads me here. #### The API ```js /** * Utility function to call a reusable flow defined as a subroutine (link-in/link-out nodes). * * @param {string} target - the target of the link-in subroutine to call (can be node ID or name of link-in node) * @param {Object} msg - the message object to pass to the subroutine * @param {Object} [options] - call options * @param {number} [options.timeout=5000] - the maximum time to wait for a response (default: 5000ms) * @return {Promise} - resolves with the returned message * @memberof @node-red/util_util */ function linkcall(target: string, msg: object, options?: object): Promise; ``` Example code in a function: ```js // get the outside temprature, send it to an AI, return YES or NO const msgTemp = (await RED.util.linkcall('get-temperature', msg)) const m2 = { payload: `Outside temperature is ${msgTemp.payload}C. Should I turn heating on? (answer YES or NO only)` } msg.payload = (await RED.util.linkcall('ask-my-ai', m2, { timeout: 30000 })).payload return msg ``` ![image](https://us1.discourse-cdn.com/flex026/uploads/nodered/original/3X/d/0/d0316ada49680095e74347a68af847cb2b710af5.png) #### Testing: behaviour of function invocation vs existing link-call ##### Sequential ![chrome_s95z51aEWX](https://us1.discourse-cdn.com/flex026/uploads/nodered/original/3X/6/2/621b56d565f5f58d434dd17fe4ca1cd62104e63c.gif) ##### Nested calls ![image](https://us1.discourse-cdn.com/flex026/uploads/nodered/original/3X/f/a/fa8c5e0cdd57261c5660e14bb254b5f5be410c62.png) ##### Missing/bad target ![image](https://us1.discourse-cdn.com/flex026/uploads/nodered/original/3X/5/3/53d334e05d6fbe3ad074eb97f14a3db551bd6e38.png) ##### Missing link-return ![image](https://us1.discourse-cdn.com/flex026/uploads/nodered/original/3X/8/a/8a6b580b3b4de25bd9d23ae1a3095e14296d8381.png) * * * Potential future improvements: - dynamic typing - present the list of targets in the intelligence as an enum choice for the `target parameter` - Support overloads to simplify calling - e.g. `RED.util.linkcall('target-name', "a string for payload for simplicity")` - e.g. `RED.util.linkcall('target-name')` // simple fire and forget (no params, dont timeout, dont care about reply msg) ---
### Author: ![TotallyInformation](https://sea2.discourse-cdn.com/flex026/user_avatar/discourse.nodered.org/totallyinformation/32/31_2.png) [@TotallyInformation](https://discourse.nodered.org/u/TotallyInformation) #### Post date: [1 February 2026 19:38 UTC](https://discourse.nodered.org/t/defining-utility-functions-for-re-use-in-a-function-node/100294/2 "2026-02-01T19:38:24Z")
Interesting. I think it would be useful to consider one additional use-case though. That is: _custom nodes that want to register utility functions_. Your example I think is fine on the visual side of things and suited to where _flow developers_ want to add utility functions. However, it does not feel well suited where node developers want to add common functions. So I'm not saying that your choice doesn't have merit, it clearly does. But I would like to see a solution for the other use-case that is more in keeping for people who are developing nodes. It feels to me as though 4 is worth pursuing but that 3 (which feels as though it should be fairly easy to implement?) would also be worth while. ---
### Author: ![Buckskin](https://avatars.discourse-cdn.com/v4/letter/b/b9e5f3/32.png) [@Buckskin](https://discourse.nodered.org/u/Buckskin) #### Post date: [1 February 2026 22:15 UTC](https://discourse.nodered.org/t/defining-utility-functions-for-re-use-in-a-function-node/100294/3 "2026-02-01T22:15:24Z")
I can see the use of option 4, but I have around 50 utility functions that I currently have in a global via IIFE that runs at flow startup so this would get messy unless there was a way of picking a function in the link. That is why I like option 3 as it gives the same kind of access. As for cons - Not visual - direct observation in the function node as to what is happening (similar to require) - Not backwards compatible - would someone really be using this in an old version of NR? Having thought about it a bit it is possible to select a function using option 4 but it is not pretty ---
### Author: ![E1cid](https://sea2.discourse-cdn.com/flex026/user_avatar/discourse.nodered.org/e1cid/32/77971_2.png) [@E1cid](https://discourse.nodered.org/u/E1cid) #### Post date: [1 February 2026 22:26 UTC](https://discourse.nodered.org/t/defining-utility-functions-for-re-use-in-a-function-node/100294/4 "2026-02-01T22:26:22Z")
Great write up Steve. I like the idea of being able to call link calls in a function node(4), would make for clearer flows and reusing functions and other nodes direct in the function node. But as other have stated I think being able to add functions with a RED.api (3) has great merit also. So I would like to see both for 3 and 4. ---
### Author: ![MyRandomThoughts](https://sea2.discourse-cdn.com/flex026/user_avatar/discourse.nodered.org/myrandomthoughts/32/41085_2.png) [@MyRandomThoughts](https://discourse.nodered.org/u/MyRandomThoughts) #### Post date: [1 February 2026 23:28 UTC](https://discourse.nodered.org/t/defining-utility-functions-for-re-use-in-a-function-node/100294/5 "2026-02-01T23:28:30Z")
I have to agree with the others, while 4 has it's merits, it doesn't work for "developers" that have many functions. Option 3 would be a better fit. For people like myself and @Buckskin, options 1 and 2 would be a non-starter I think. ---
### Author: ![bakman2](https://sea2.discourse-cdn.com/flex026/user_avatar/discourse.nodered.org/bakman2/32/6207_2.png) [@bakman2](https://discourse.nodered.org/u/bakman2) #### Post date: [2 February 2026 05:06 UTC](https://discourse.nodered.org/t/defining-utility-functions-for-re-use-in-a-function-node/100294/6 "2026-02-02T05:06:27Z")
To make it user friendly, perhaps in conjunction with #3: ![image](https://us1.discourse-cdn.com/flex026/uploads/nodered/original/3X/e/e/ee4940313a8f17703dd087cbc74b8129696df1b8.jpeg) in that 'functions' section, have an overview of defined functions, where the user can add/modify/delete. This could perhaps also be used for installing external modules, removing the need for the 'setup' tab in function nodes (thinking out loud) ---
### Author: ![Steve-Mcl](https://sea2.discourse-cdn.com/flex026/user_avatar/discourse.nodered.org/steve-mcl/32/4826_2.png) [@Steve-Mcl](https://discourse.nodered.org/u/Steve-Mcl) #### Post date: [2 February 2026 08:43 UTC](https://discourse.nodered.org/t/defining-utility-functions-for-re-use-in-a-function-node/100294/7 "2026-02-02T08:43:31Z")
> [@bakman2](#): > > To make it user friendly, perhaps in conjunction with #3: #1 is a half baked idea that I didn't really word well. I did mean centralised management (I said it but called it a config for ease) and would probably have deferred to this design once if I put more than 5 mins thought into it πŸ˜‰ The issue with the config / global settings version of this story is the amount of UI work and other scaffolding (like import/export, search/discoverability, where to store and instantiate functions) (its not a quick win) > [@MyRandomThoughts](#): > > I have to agree with the others, while 4 has it's merits, it doesn't work for "developers" that have many functions. Option 3 would be a better fit. > [@Buckskin](#): > > I can see the use of option 4, but I have around 50 utility functions that I currently have in a global via IIFE that runs at flow startup so this would get messy unless there was a way of picking a function in the link. Well, yes, of course you could have a single link-flow-subroutine with many functions - for example could simply pass the function name and args in the msg ![chrome_pvz6MU8sbi](https://us1.discourse-cdn.com/flex026/uploads/nodered/original/3X/3/d/3d624576615529e393e79c6c03cb74d83f481f27.gif) A little clunkier but would be possible with #4. > [@E1cid](#): > > being able to add functions with a RED.api (3) has great merit also. So I would like to see both for 3 and 4. > [@TotallyInformation](#): > > It feels to me as though 4 is worth pursuing but that 3 (which feels as though it should be fairly easy to implement?) would also be worth while. > [@MyRandomThoughts](#): > > Option 3 would be a better fit. > [@Buckskin](#): > > That is why I like option 3 It seems Option 3 is winning more hearts but I fear they might be for the same selfish reasons I like options 3 (its just easier to set-up a bunch of functions in a code block), but, Option 3 alone would provide a lot less benefits that Option 4. I understand (as a programmer and lazy person (the best kinda lazy)) why #3 is more attractive but it is ultimately a bit harder to implement and a fair bit more restrictive than #4. So, perhaps a combination of the 2 solutions is the answer!. An API that not only lets you call linkTargets but declare reusable functions too. That way, when you need to call upon the functionality of a contrib node, you can. When you need a simple utility function, you get that too. That said, I think both #4 and #3 are achievable (#4 obviously since I have a working PoC) but #3 was something I wrote a few months back. The hardest parts were the API naming and parameters (for picking up function signatures/jsdoc for monaco), presenting the generated functions as real things in the monaco editor dynamically and where they live/execute (I chose global context) but was never truly happy with it - too many what-if edge cases - something that didnt crop up when doing #4! I will let it swish around my head for a few days (and see if there is any other feedback in the coming days). ---
### Author: ![TotallyInformation](https://sea2.discourse-cdn.com/flex026/user_avatar/discourse.nodered.org/totallyinformation/32/31_2.png) [@TotallyInformation](https://discourse.nodered.org/u/TotallyInformation) #### Post date: [2 February 2026 12:52 UTC](https://discourse.nodered.org/t/defining-utility-functions-for-re-use-in-a-function-node/100294/8 "2026-02-02T12:52:37Z")
> [@Steve-Mcl](#): > > It seems Option 3 is winning more hearts but I fear they might be for the same selfish reasons I like options 3 (its just easier to set-up a bunch of functions in a code block), but, Option 3 alone would provide a lot less benefits that Option 4. > > I understand (as a programmer and lazy person (the best kinda lazy)) why #3 is more attractive This is not about being selfish or lazy - from my perspective anyway. I've already abused `RED.util` for uibuilder to expose some useful functions to function nodes. Others have said similar things. There is clearly a need here. I would hope for something like a `RED.fns` object to be exposed where nodes can declare a unique property root, for example `RED.fns.uibuilder` for uibuilder. That root would allow functions or perhaps also constants to be added at least by custom nodes. Ideally, there would also be a method for non-node authors to also similarly add a collection of functions. For safety, it might be wise to add a switch/flag to settings.js to allow turning the feature off though. If you want a REALLY easy way to enable this just for node developers, you could simply make it official that nodes can use `RED.util` for adding custom functions. With, of course, suitable warnings about name collisions. > [@Steve-Mcl](#): > > a bit harder to implement and a fair bit more restrictive than #4 Not sure about harder, since everything is node.js under the skin, I _think_ this should be fairly easy. But yes, it _should_ be more restrictive which is why most of us are also saying that option 4 should also be considered in parallel. > [@Steve-Mcl](#): > > That way, when you need to call upon the functionality of a contrib node, you can. When you need a simple utility function, you get that too. Which is great for visual developers but naff for node developers. > [@Steve-Mcl](#): > > (for picking up function signatures/jsdoc for monaco) Well, this would be **fantastic** to have. But, not really necessary for a first release. So if time/resources are short, maybe this part should be considered for v5.1? > [@Steve-Mcl](#): > > where they live/execute (I chose global context) but was never truly happy with it - too many what-if edge cases Off the top of my head, I would agree. I don't think that global context would be good for #3, it is specifically for function nodes isn't it? So it should be a function node API. It really doesn't make sense to expose #3 to anything else I don't think? ---
### Author: ![jbudd](https://avatars.discourse-cdn.com/v4/letter/j/5f8ce5/32.png) [@jbudd](https://discourse.nodered.org/u/jbudd) #### Post date: [2 February 2026 14:16 UTC](https://discourse.nodered.org/t/defining-utility-functions-for-re-use-in-a-function-node/100294/9 "2026-02-02T14:16:20Z")
Not sure if this is relevant to the topic? From the point of view of a non-native javacript speaker: I know that if I want to include an extra library in a function node, I can include the library in the On Setup tab. It seems to be a perfectly adequate mechanism to access extra functions. I would not welcome a distinct way to include more just because I wrote them myself. Briefly I used the functions defined in global context approach, but I abandoned it as too unwieldy. I don't care how it works in the background but I think the code should be included in the function explicitly rather than globally, and in exactly the same way as I currently include eg the chroma-js library. ---
### Author: ![Buckskin](https://avatars.discourse-cdn.com/v4/letter/b/b9e5f3/32.png) [@Buckskin](https://discourse.nodered.org/u/Buckskin) #### Post date: [2 February 2026 14:38 UTC](https://discourse.nodered.org/t/defining-utility-functions-for-re-use-in-a-function-node/100294/10 "2026-02-02T14:38:00Z")
> [@TotallyInformation](#): > > So it should be a function node API. It really doesn't make sense to expose #3 to anything else I don't think? I would agree with that. Steve's solution to using option 4 was better than mine (giant switch statement) but I have thought of another way: keep the library as an IIFE and return the whole thing as a msg property which can then be collected as part of a link call. (individual functions can also be returned) Non functional example (no functions include) ```auto const utility = (function () { 'use strict'; /* * Static Properties * libraryVersion v 2.2 * * Functions Available * * fixedDecimals, * roundToHalf, v 2.1 * toSentenceCase, * toTitleCase, * toCamelCase, * camelCaseToText, * dewPoint v 2.2 * */ const libraryVersion = 2.2 . . . . return { libraryVersion, fixedDecimals, roundToHalf, toSentenceCase, toTitleCase, toCamelCase, camelCaseToText, dewPoint, } }()) msg.utility = utility msg.utilityFunction = utility[msg.payload] return msg ``` ---
### Author: ![TotallyInformation](https://sea2.discourse-cdn.com/flex026/user_avatar/discourse.nodered.org/totallyinformation/32/31_2.png) [@TotallyInformation](https://discourse.nodered.org/u/TotallyInformation) #### Post date: [2 February 2026 16:29 UTC](https://discourse.nodered.org/t/defining-utility-functions-for-re-use-in-a-function-node/100294/11 "2026-02-02T16:29:05Z")
> [@Buckskin](#): > > return the whole thing as a msg property which can then be collected as part of a link call. (individual functions can also be returned) Unfortunately, I think that approach is somewhat fragile because functions cannot be serialized. It may work but there might be unforeseen circumstances where it would not. ---
### Author: ![Buckskin](https://avatars.discourse-cdn.com/v4/letter/b/b9e5f3/32.png) [@Buckskin](https://discourse.nodered.org/u/Buckskin) #### Post date: [2 February 2026 17:52 UTC](https://discourse.nodered.org/t/defining-utility-functions-for-re-use-in-a-function-node/100294/12 "2026-02-02T17:52:19Z")
Possibly, what sort of circumstances were you thinking of, (I have to add that this is not my preferred approach which is option 3) At the moment I recreate the library global whenever the first flow starts because, as you say, a function cannot be serialised and therefore cannot be saved in a file. However, with the approach posited each time the link call runs the IIFE function recreates the entire library so it never has to be saved. The only downside is that the library functions ARE recreated each time the link call runs. ---
### Author: ![gdvine](https://sea2.discourse-cdn.com/flex026/user_avatar/discourse.nodered.org/gdvine/32/101799_2.png) [@gdvine](https://discourse.nodered.org/u/gdvine) #### Post date: [2 February 2026 22:21 UTC](https://discourse.nodered.org/t/defining-utility-functions-for-re-use-in-a-function-node/100294/13 "2026-02-02T22:21:21Z")
Just throwing my hat in the ring to describe what I do. It works great! 1. In my `Start Run` subflow, I have a `Lib` node that defines an object full of the shared functions I want available everywhere that gets saved to global context as `lib`, if not already present. 2. Soon afterward, I hoist that context to `msg.lib` for direct use in the rest of the flow. 3. Calling happens like this: `const myDataBlob = msg.lib.data.getCurrenBlob(msg);` I often send in `msg` so the given lib method will have the data context it needs to do stuff. For utilities, often it helps to send in `node` as well so you can do stuff with the caller node’s context. ---
### Author: ![omrid](https://avatars.discourse-cdn.com/v4/letter/o/77aa72/32.png) [@omrid](https://discourse.nodered.org/u/omrid) #### Post date: [3 February 2026 10:03 UTC](https://discourse.nodered.org/t/defining-utility-functions-for-re-use-in-a-function-node/100294/14 "2026-02-03T10:03:37Z")
> [@TotallyInformation](#): > > Unfortunately, I think that approach is somewhat fragile because functions cannot be serialized. It may work but there might be unforeseen circumstances where it would not. IMHO, it is possible to pass functions as msg properties/return values in flows, without any need for serialization. A node is actually a JS function (registered dynamically into the Node-red runtime). "Sending a message" to a node is actually calling that node directly (with the parameter `msg`), which then invokes a callback handler, **all in the same memory space**. This will not work for dashboard nodes (widgets) where `msg` does need to be serialized when sent/received over a socket. But even here it is easy to serialize functions, as I do in my `@omrid01/node-red-dashboard-2-table-tabulator` dashboard node, where custom callback functions can be defined & sent as metadata objects (with name, parameters & body), and instantiated at the client side e.g. `myFunc = new Function()`. ---
### Author: ![TotallyInformation](https://sea2.discourse-cdn.com/flex026/user_avatar/discourse.nodered.org/totallyinformation/32/31_2.png) [@TotallyInformation](https://discourse.nodered.org/u/TotallyInformation) #### Post date: [3 February 2026 11:05 UTC](https://discourse.nodered.org/t/defining-utility-functions-for-re-use-in-a-function-node/100294/15 "2026-02-03T11:05:04Z")
> [@omrid](#): > > it is possible to pass functions as msg properties/return values in flows, without any need for serialization. All I was doing was pointing out that there may be edge-cases to take into account. For example, people often forget that, while you can put a function into a context variable - you can only do so if you are using the in-memory based context. These things are easy to forget but I don't have enough knowledge of the deep workings of the Node-RED core to be able to say whether or not this would need dealing with in this instance. Just that some measure of care is needed. ---
### Author: ![dubnemo](https://sea2.discourse-cdn.com/flex026/user_avatar/discourse.nodered.org/dubnemo/32/38759_2.png) [@dubnemo](https://discourse.nodered.org/u/dubnemo) #### Post date: [6 February 2026 18:57 UTC](https://discourse.nodered.org/t/defining-utility-functions-for-re-use-in-a-function-node/100294/16 "2026-02-06T18:57:51Z")
I previously suggested to be able to call a reuseable (registered) function from within JSONata, similar to other transformation languages (DataWeave, XSLT). ---
### Author: ![PKBreck](https://sea2.discourse-cdn.com/flex026/user_avatar/discourse.nodered.org/pkbreck/32/101982_2.png) [@PKBreck](https://discourse.nodered.org/u/PKBreck) #### Post date: [7 February 2026 06:09 UTC](https://discourse.nodered.org/t/defining-utility-functions-for-re-use-in-a-function-node/100294/17 "2026-02-07T06:09:38Z")
Probably a naive suggestion, but it seems this is at core a lexical/name space scoping problem.Right now all JS functions must appear in a node. So the scope/lifetime is limited to that node. The Context Store already provides a paradigm for managing / advertising namespaces at the node/page global level. So, what if a "function" type of variable could be added to the Context Store? Values would be normal JS text. The desired function could be invoked within a Function Node, for example, with a new "run" function put alongside the set\* and get\* API entries. "run" of course would have to pass variable length argument lists which might be a non-trivial feature ---
### Author: ![system](https://us1.discourse-cdn.com/flex026/uploads/nodered/original/1X/d073cd938eafa2e558d7c2cd59003b3ef4963033.png) [@system](https://discourse.nodered.org/u/system) #### Post date: [8 April 2026 06:10 UTC](https://discourse.nodered.org/t/defining-utility-functions-for-re-use-in-a-function-node/100294/18 "2026-04-08T06:10:10Z")
This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.