Hacktoberfest 2026: những issue maintainer đã đánh dấu cho tháng Mười, đang mở và phù hợp người mới. Xem issue Hacktoberfest

NR5: Type definitions for Nodes

Đang mở
  • Có gì không ổn?
#5,535 11 bình luận 4 reaction 1 người được giao Xem trên GitHub

Maintainer thường phản hồi trong vòng 1 ngày

@knolleary đang làm issue này rồi.

Từ ngày 6/3/2026.

Đánh giá

Issue này chưa được đánh giá.

Mô tả

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.

Ngôn ngữ chính
JavaScript
Star
23.7k
Fork
3.9k
Merge trung bình
1 ngày
Pull request đã merge (30 ngày)
11

Chuẩn bị môi trường

Bắt đầu từ đâu

  1. Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
  2. Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
  3. Fork repository và làm thay đổi trên một nhánh.
  4. Mở pull request có tham chiếu số hiệu của issue.

Issue khác của node-red/node-red

Tất cả issue của node-red/node-red

Issue tương tự

Thêm issue về JavaScript

Nhận issue mới trong hộp thư của bạn

Bản tóm tắt ngắn những issue GitHub phù hợp với người mới.