Hacktoberfest 2026: as issues que os mantenedores marcaram para outubro, abertas e boas para iniciantes. Ver issues do Hacktoberfest

NR5: Type definitions for Nodes

Aberta
  • Algo errado?
#5,535 11 comentários 4 reações 1 responsável Ver no GitHub

Mantenedores costumam responder em até 2 dias

@knolleary já está trabalhando nisso.

Desde 6/3/2026.

Avaliação

Esta issue ainda não foi avaliada.

Descrição

project-modernization

This is a long running topic of discussion that has never quite bridged the chasm 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.

Linguagem predominante
JavaScript
Estrelas
23.7k
Forks
3.9k
Merge médio
4d 37min
PRs com merge (30d)
25

Preparar o ambiente

Primeiros passos

  1. Leia a issue inteira e depois o guia de contribuição do projeto.
  2. Comente na issue dizendo que vai assumir — evita que duas pessoas façam o mesmo trabalho.
  3. Faça um fork do repositório e trabalhe em uma branch.
  4. Abra um pull request que referencie o número da issue.

Mais de node-red/node-red

Todas as issues de node-red/node-red

Issues semelhantes

Mais issues de JavaScript

Receba novas issues na sua caixa de entrada

Um resumo curto de issues do GitHub para quem está começando.