# Dreaming of typescript

**URL:** <https://discourse.nodered.org/t/dreaming-of-typescript/100533>\
**Category:** General\
**Created:** [10 March 2026 19:27 UTC](https://discourse.nodered.org/t/dreaming-of-typescript/100533 "2026-03-10T19:27:26Z")\
**Posts on this page:** 20\
**Page:** 1

<div class="post-metadata">

**Author:** ![ThingsTinkerer](https://avatars.discourse-cdn.com/v4/letter/t/91b2a8/32.png) [@ThingsTinkerer](https://discourse.nodered.org/u/ThingsTinkerer)\
**Post date:** [10 March 2026 19:27 UTC](https://discourse.nodered.org/t/dreaming-of-typescript/100533/1 "2026-03-10T19:27:26Z")

</div>

Imagine for a second the possibility of typescript support in addition or instead of javascript. What would that look like? You could declare the type of each output connection, and by that get notification whenever you wire up nodes that are incompatible! You would be notified when access a property in msg that doesn't exist (instead of finding out eventually...). The feedback loop is instant! It would probably be enough to declare the output type, and the rest would solve itself. I am currently managing several NR instances for monitoring and controlling building energy, and more often than I'd like, there are some part in need of updates. But when copying code and apply to all instances, well they're not all identical. Sometimes it will be logged, other times it will not. I don't test everything every time. Regression bugs do happen from time to time. Ts would eliminate most if not all of them instantly. I know that an alternative ts function node exists, but last time I checked it doesn't support NR lint, not willing to make that choice. As much as I enjoy js, I started a ts project recently and realized how much I missed it. My dream of first-class support in NR continues.

---

<div class="post-metadata">

**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:** [10 March 2026 20:03 UTC](https://discourse.nodered.org/t/dreaming-of-typescript/100533/2 "2026-03-10T20:03:11Z")

</div>

> [@ThingsTinkerer](#):
>
> instead of javascript

NO!!!!

This would kill Node-RED for me. Even the use of Typescript in some areas of Node-RED code would likely end any attempt by me to offer support or extension.

Also, have you used VSCode's typescript support in writing JavaScript for the DOM? It STINKS! I generally have to turn it off as it gets so many things wrong ("property X does not exist on HTMLElement"! Cr&p.)

Typescript is useful for large development teams. It is just another non-native language getting in the way for us hobbyists.

---

<div class="post-metadata">

**Author:** ![marcus-j-davies](https://sea2.discourse-cdn.com/flex026/user_avatar/discourse.nodered.org/marcus-j-davies/32/103435_2.png) [@marcus-j-davies](https://discourse.nodered.org/u/marcus-j-davies)\
**Post date:** [10 March 2026 20:07 UTC](https://discourse.nodered.org/t/dreaming-of-typescript/100533/3 "2026-03-10T20:07:51Z")

</div>

Julian likes typescript - can you tell? 😃

Getting very close to releasing v11 of my Node, it did start as a typescript project.

it become to involved, and..... unnecessary?

I don't mind typescript - but I would have to agree with Julian, better left for extremely large projects, where MANY developers are involved, that might not know the types involved in said project

---

<div class="post-metadata">

**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:** [10 March 2026 20:22 UTC](https://discourse.nodered.org/t/dreaming-of-typescript/100533/4 "2026-03-10T20:22:08Z")

</div>

> [@marcus-j-davies](#):
>
> that might not know the types involved in said project

Check out my uibuilder nodes. They are chock full of JSDoc based type direction. I even now produce a typedefs file for the client library (but only because Claude can do it for me, if I didn't have that, I couldn't/wouldn't do it). As I say, I often have to turn off the typescript linting due to the poor support for certain types of object (notably the DOM and Node-RED!).

The JSDoc typings are mostly in collapsible comments so they don't get in the way of programming but VScode still gives me hints and whinges at me if I've gone too far off the rails.

---

<div class="post-metadata">

**Author:** ![ThingsTinkerer](https://avatars.discourse-cdn.com/v4/letter/t/91b2a8/32.png) [@ThingsTinkerer](https://discourse.nodered.org/u/ThingsTinkerer)\
**Post date:** [10 March 2026 23:01 UTC](https://discourse.nodered.org/t/dreaming-of-typescript/100533/5 "2026-03-10T23:01:26Z")

</div>

> [@marcus-j-davies](#):
>
> pers are involved, that might not know the types involved in said project

It is enough to write a prop slightly different in one instance to make all sorts of problems that turned out to be invisible except for some missing output (among a lot of output). Could be you or another team member forgot precisely how to name that prop. And for how long do you remember the exact names of props anyway? Months? weeks? days? 1-2 people is hardly a big team!

---

<div class="post-metadata">

**Author:** ![ThingsTinkerer](https://avatars.discourse-cdn.com/v4/letter/t/91b2a8/32.png) [@ThingsTinkerer](https://discourse.nodered.org/u/ThingsTinkerer)\
**Post date:** [10 March 2026 23:04 UTC](https://discourse.nodered.org/t/dreaming-of-typescript/100533/6 "2026-03-10T23:04:00Z")

</div>

Currently working on a react project and seems smooth so far in vscode. I will be adjusting configs and settings ruthlessly to get the correct feedback. But for this topic, can set strict mode default off as compromise haha.

---

<div class="post-metadata">

**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:** [10 March 2026 23:16 UTC](https://discourse.nodered.org/t/dreaming-of-typescript/100533/7 "2026-03-10T23:16:04Z")

</div>

> [@ThingsTinkerer](#):
>
> Could be you or another team member forgot precisely how to name that prop

You have a TEAM for writing nodes? I think most of us are single devs. 😃 By all means use TS to create you nodes, this is entirely up to you. Just don't, please, force it on those of us for whom it is an unnecessary overhead with no benefit.

---

<div class="post-metadata">

**Author:** ![ThingsTinkerer](https://avatars.discourse-cdn.com/v4/letter/t/91b2a8/32.png) [@ThingsTinkerer](https://discourse.nodered.org/u/ThingsTinkerer)\
**Post date:** [10 March 2026 23:29 UTC](https://discourse.nodered.org/t/dreaming-of-typescript/100533/8 "2026-03-10T23:29:45Z")

</div>

We have a team working professionally using NR yes. Life is great!

---

<div class="post-metadata">

**Author:** ![AllanOricil](https://sea2.discourse-cdn.com/flex026/user_avatar/discourse.nodered.org/allanoricil/32/106911_2.png) [@AllanOricil](https://discourse.nodered.org/u/AllanOricil)\
**Post date:** [11 March 2026 13:53 UTC](https://discourse.nodered.org/t/dreaming-of-typescript/100533/9 "2026-03-11T13:53:25Z")

</div>

@ThingsTinkerer nodes written with the NRG (acronym to node-red generator) framework are going to fix that

> **[GitHub - AllanOricil/node-red-vue-template at wip\_ts](https://github.com/AllanOricil/node-red-vue-template/tree/wip_ts)**
>
> Write Node-RED nodes using Vue and Typescript. Contribute to AllanOricil/node-red-vue-template development by creating an account on GitHub.

I'm very close to releasing it. Input/Outputs/Configs/Credentials/Settings are all typechecked at runtime and build time. Nodes are properly encapsulated using classes and are typed during development. For example, inside a node you can now get runtime typed config nodes

```ts
// NOTE: remoteServer is a config node
const server = this.config.remoteServer;
if (server instanceof RemoteServerConfigNode) {
   // NOTE: this message will be logged :D
   this.log("server is an instance of RemoteServerConfigNode");
}

```

Disregard the README docs, because lot of things have changed and read the code in `./server` and `./client` folders to understand how to create nodes.

I recommend not writting nodes with it yet because I'm still working on the API design and dev tooling. Things might change. Just use it to learn and give me feedback if possible.

Besides improving the overall design of nodes, I also developed vite plugin to ease development, and standardize the distribution of packages.

```bash
pnpm dev => start dev server
pnpm build => create distro at ./dist

```

This template will be part of the NRG CLI v3.

---

<div class="post-metadata">

**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:** [11 March 2026 14:25 UTC](https://discourse.nodered.org/t/dreaming-of-typescript/100533/10 "2026-03-11T14:25:00Z")

</div>

Of course, there is only 1 minor issue when writing nodes in TypeScript even now. That is that the compiled output likely won't have the same source lines as the source code so debugging errors can be somewhat tricky. I discovered that myself when I played with a build step using ESBUILD for my nodes (one of my experiments when looking to be able to use ESM's for nodes prior to node.js catching up with allowing ESM's in CommonJS modules). There is a work-around but it requires running Node-RED with a node.js flag to allow the use of map files.

---

<div class="post-metadata">

**Author:** ![ThingsTinkerer](https://avatars.discourse-cdn.com/v4/letter/t/91b2a8/32.png) [@ThingsTinkerer](https://discourse.nodered.org/u/ThingsTinkerer)\
**Post date:** [11 March 2026 14:28 UTC](https://discourse.nodered.org/t/dreaming-of-typescript/100533/11 "2026-03-11T14:28:48Z")

</div>

Perhaps I should clarify, I don't write nodes as in design nodes as packages/palette. I write function nodes and make subflows in NR. It covers 90% of what I need and the rest seems like a big jump. But having automated instant feedback on all props in all these function nodes and subflows would be great. Perhaps ts could even "see" how a msg builds up and make type dynamically from it instead of predeclaring all types.

---

<div class="post-metadata">

**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:** [11 March 2026 14:39 UTC](https://discourse.nodered.org/t/dreaming-of-typescript/100533/12 "2026-03-11T14:39:27Z")

</div>

OK, I get it. 😃

> [@ThingsTinkerer](#):
>
> having automated instant feedback on all props in all these function nodes and subflows would be great

For sure. But one opposing thought if I may. One of the strengths (IMHO) of Node-RED is that you DON'T have to concern yourself with enforced schema's. This is what makes NR such a great prototyping tool. And it lends itself to things like home automation.

So while I certainly see the benefits of having such things available, in my view, they _should never be mandated_. Such as might be implied from your first post and why I responded so vehemently.

Indeed, such a change would destroy the flows of, I would guess, by far the majority of people. And would add significant complexity to many flows since you would now need to provide handling for edge cases and complex data inputs that previously you might have been able to ignore.

---

<div class="post-metadata">

**Author:** ![ThingsTinkerer](https://avatars.discourse-cdn.com/v4/letter/t/91b2a8/32.png) [@ThingsTinkerer](https://discourse.nodered.org/u/ThingsTinkerer)\
**Post date:** [11 March 2026 17:50 UTC](https://discourse.nodered.org/t/dreaming-of-typescript/100533/13 "2026-03-11T17:50:43Z")

</div>

I'll go as far as grant you strict mode off haha 😄

---

<div class="post-metadata">

**Author:** ![kuema](https://sea2.discourse-cdn.com/flex026/user_avatar/discourse.nodered.org/kuema/32/6542_2.png) [@kuema](https://discourse.nodered.org/u/kuema)\
**Post date:** [12 March 2026 07:05 UTC](https://discourse.nodered.org/t/dreaming-of-typescript/100533/14 "2026-03-12T07:05:17Z")

</div>

FYI: There is already an ongoing discussion about node type definitions on Github 😉

> <https://github.com/node-red/node-red/issues/5535>
>
> This is a long running topic of discussion that has never quite bridged the chas…m to getting an issue raised to start solidifying plans around it.
> 
> It is also a topic that gets interpreted in many different ways. The goal here is to have a well-defined scope and purpose. There are some short-term requirements, some long-term aspirations and a whole load of things in between. We aren't going to solve everything in one go.
> 
> The goal here is to have a mechanism for nodes to declare type information in a standard way.
> 
> This covers:
> - node configuration properties
> - inbound message properties
> - outbound message properties
> 
> There are lots of potential use-cases for the typings, and whilst I list some examples here, I want to be as clear as possible that they are for future consideration and we're not proposing to implement them at this stage. I'm listing them here to help inform \*how\* the types \*could\* be used - and that may influence choices made
> 
> - Automatic validation of flow files. Currently we can validate the basic structure of a flow, but we cannot validate a node configuration as we don't know what it should look like.
> - Automatic generation of edit dialog. For many nodes, the edit form has a direct correlation to its properties. It should be possible to generate the edit form from the type definition. Of course there are plenty of edge cases, and it only really works for simple configs, but its something to keep in mind
> - Runtime validation of flows.
> - UI tooling to help map message properties between nodes without having to use debug to examine messages
> - AI-driven flow generation
> 
> Each of these use cases has its own pros/cons and being in that list doesn't mean we'll do them. This issue is \*not\* intended to be a discussion of their individual merits, as much as you might like to comment on them.
> 
> Types cannot be mandatory as we have 5000+ existing nodes that don't have type information. But, over time, the types should bring sufficient benefit to end-users that node authors are inclined to include them.
> 
> \## Scope
> 
> - The goal for NR 5.0 will be to have a documented method for how nodes can provide type information.
> - The core Node-RED nodes should be updated to include type information.
> - No runtime/editor functional changes related to the typings
> 
> \### Format of the typings
> 
> There are two possible formats. JSONSchema, or TypeScript style definitions. My instinct is the JSONSchema route, but will need to evaluate what makes most sense. I like JSON as its a well defined blob that can be transported easily. A TypeScript file is free form text and makes me twitch.
> 
> It's conceivable that some use cases may require a bit more meta-data (eg, hints on UI generation). We may need to be a little custom - as long as we have a schema to validate the schema...
> 
> \### Location of typings
> 
> There are three different places the typings could be consumed; editor, runtime and through static analysis without running anything. This third category is an interesting lesson to learn from the Flow Library; working out meta-data about a node from an npm package is quite hard to do as it's all done in code.
> 
> My starting point for this will be to look for a type file that sits alongside the node.js/html files. Need to pick a suitable filename format that aligns with the format of the typings and other conventions.

---

<div class="post-metadata">

**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:** [12 March 2026 13:06 UTC](https://discourse.nodered.org/t/dreaming-of-typescript/100533/15 "2026-03-12T13:06:07Z")

</div>

A sensible approach. Nice to see a basic start targeted for v5.

---

<div class="post-metadata">

**Author:** ![GogoVega](https://sea2.discourse-cdn.com/flex026/user_avatar/discourse.nodered.org/gogovega/32/71313_2.png) [@GogoVega](https://discourse.nodered.org/u/GogoVega)\
**Post date:** [12 March 2026 16:25 UTC](https://discourse.nodered.org/t/dreaming-of-typescript/100533/17 "2026-03-12T16:25:49Z")

</div>

Note also that a more realistic approach is to use TS types in combination with JSDoc comments. This benefits both the core and third-party developers.

> <https://github.com/node-red/node-red/pull/5147>
>
> \## Types of changes
> 
> \- \[\] Bugfix (non-breaking change which fixes an issue)
> …- \[x\] New feature (non-breaking change which adds functionality)
> 
> \## Proposed changes
> 
> Adds types for the \`editor-client\` package.
> 
> These types are intended for:
> 
> \- core developers (nothing to do - RED and jQuery are declared globally)
> \- third-party node developers (by importing types with JSDoc or TypeScript)
> 
> TODO list:
> 
> \- \[\] Check all types (to the extent of this v1)
> \- \[\] Define what is internal or not
> 
> \## Checklist
> 
> \- \[x\] I have read the \[contribution guidelines\](https://github.com/node-red/node-red/blob/master/CONTRIBUTING.md)
> \- \[x\] For non-bugfix PRs, I have discussed this change on the forum/slack team.
> \- \[x\] I have run \`npm run test\` to verify the unit tests pass
> \- \[\] I have added suitable unit tests to cover the new/changed functionality

---

<div class="post-metadata">

**Author:** ![knolleary](https://sea2.discourse-cdn.com/flex026/user_avatar/discourse.nodered.org/knolleary/32/3_2.png) [@knolleary](https://discourse.nodered.org/u/knolleary)\
**Post date:** [12 March 2026 16:40 UTC](https://discourse.nodered.org/t/dreaming-of-typescript/100533/19 "2026-03-12T16:40:56Z")

</div>

@AllanOricil I saw your comment on the issue, I was in the middle of replying but the comment has since been deleted, so I'll reply here.

The issue is the start of the _discussion_. You have implemented an entire framework with NRG without any discussion or consultation. You have declared you have the best solution. That may be the case, but we need to evaluate what is right for the core Node-RED experience.

The question over whether TypeScript typings or JSON Schema based solutions (or Zod, or something else) is an active one. There are trade-offs across the board on it and lots of different use cases to consider.

I'm not personally a fan of TypeScript definitions for nodes as we need a mechanism that can apply to not only node properties, but also the messages they send and receive.

We need a mechanism that can _statically_ validate a flow json - without having to run nodes to access their schemas.

My current thinking is that JSON Schema works at the base layer - but doesn't preclude building a tool chain on top that generates the schema from TypeScript/Zod or whatever the node author wants to do.

---

<div class="post-metadata">

**Author:** ![AllanOricil](https://sea2.discourse-cdn.com/flex026/user_avatar/discourse.nodered.org/allanoricil/32/106911_2.png) [@AllanOricil](https://discourse.nodered.org/u/AllanOricil)\
**Post date:** [12 March 2026 17:41 UTC](https://discourse.nodered.org/t/dreaming-of-typescript/100533/20 "2026-03-12T17:41:16Z")

</div>

> [@knolleary](#):
>
> I'm not personally a fan of TypeScript definitions for nodes as we need a mechanism that can apply to not only node properties, but also the messages they send and receive.

This has already been sorted too. Configs, Credentias, Settings, Input and Outputs messages. All dynamically typed with the source of truth being a Typed Json Schema, made with Typebox. I didnt use zod because it is slow and it is not compatible with json schemas. Typebox let us generate and export types and json schemas. It also let us use plain json schemas if people dont like using typescript to declare them. Just look at my work.

---

<div class="post-metadata">

**Author:** ![knolleary](https://sea2.discourse-cdn.com/flex026/user_avatar/discourse.nodered.org/knolleary/32/3_2.png) [@knolleary](https://discourse.nodered.org/u/knolleary)\
**Post date:** [12 March 2026 17:59 UTC](https://discourse.nodered.org/t/dreaming-of-typescript/100533/21 "2026-03-12T17:59:15Z")

</div>

> [@AllanOricil](#):
>
> Just look at my work.

Where should we be looking? I know you've shared links previously in other threads, but it would be helpful to have a link rather than have to go digging for it.

As I said, my current thinking is the base layer should be JSON Schema. If a node author choses to use a toolchain/framework to generate that schema, then that's great - and there's plenty of space for that to happen. But they key, at this stage, is to get the base layer defined.

---

<div class="post-metadata">

**Author:** ![knolleary](https://sea2.discourse-cdn.com/flex026/user_avatar/discourse.nodered.org/knolleary/32/3_2.png) [@knolleary](https://discourse.nodered.org/u/knolleary)\
**Post date:** [12 March 2026 18:07 UTC](https://discourse.nodered.org/t/dreaming-of-typescript/100533/22 "2026-03-12T18:07:09Z")

</div>

Another key point is we need a mechanism for existing nodes to declare typings without forcing them to complete rewrite themselves in a particular framework. That means keeping it as light-weight as possible for an existing module to adopt.

[Next page](https://discourse.nodered.org/t/dreaming-of-typescript/100533.md?page=2)