Template V3: GitHub - AllanOricil/node-red-vue-template: Write Node-RED nodes using Vue and Typescript · GitHub
@bonsae/nrg: GitHub - bonsaedev/nrg: Build Node-RED nodes with Vue 3, TypeScript, and JSON Schema · GitHub
Soon @bonsae/create-nrg will be available to ease the scaffolding of Node-RED nodes built with nrg
What's New
v3 is a complete rewrite powered by the @bonsae/nrg framework.
Zero-Config Client
The entire src/client/ directory is now optional. Your nodes are automatically registered based on their server-side class definitions — no client code required.
- No client/index.ts — node registration is auto-generated at build time
- No client/components/{type}.vue — forms are rendered automatically from your Config and Credentials schemas
- No client/nodes/{type}.ts — category, color, inputs, outputs, and icon are read from the server class
Only create client files when you need to:
- components/{type}.vue — custom form UI beyond what the schema generates
- nodes/{type}.ts — client-only hooks like onPaletteAdd or custom label functions
- index.ts — control registration order or add custom initialization
Server-Driven Schemas
Define your node's config, credentials, input, and output schemas once using TypeBox. The framework uses them everywhere:
- TypeScript type inference (Infer)
- Server-side validation (AJV)
- Client-side real-time validation
- Auto-generated editor forms
- Pre-computed defaults at build time
Config and Credentials schemas are optional. When provided, they define the node's editable properties, generate the editor form automatically, and enable client-side
validation. Without them, the node appears in the palette with no configuration panel.
Input and Output schemas are also optional. When provided, users get a toggle in the editor to enable runtime message validation per node instance. This is useful for:
- Catching unexpected message shapes during development
- Enforcing contracts between nodes in production flows
You don't need to define every field in your input/output schemas. Use them as a base contract — validate the fields you care about and let the rest pass through.
Node-RED messages are plain JavaScript objects that can carry arbitrary properties, so your schemas should reflect only what your node actually reads or writes, not the
entire message structure.
Even without schemas, you can still provide TInput and TOutput type parameters to the IONode generic class for full TypeScript type safety in your input() and send()
methods. In the future, these type parameters will enable compile-time wiring validation — the framework will be able to verify that connected nodes have compatible
input/output types, catching wiring errors before deployment.
Other Highlights
- ESM server build with auto-generated CJS bridge for Node-RED compatibility
- Per-instance validation toggles — users can enable input/output validation from the editor
- Per-port output validation — outputsSchema accepts Schema[] for multi-output nodes
- Dynamic output ports — include outputs in your config schema and users can change it from the editor
- Simplified lifecycle — done() is called automatically, this.send() works everywhere, timers auto-cleanup
- Type-checking before build — pnpm build runs tsc before bundling
- Source maps in production builds for easier debugging
- automatic deregistration of timers when using internal timer methods
- beter APIs
- new hooks: registered and created
- support of ESM only dependencies
- a lot more
auto-wired-node form was fully generated by nrg at build time based on the schemas defined at ./src/server/nodes/auto-wired-node.ts class
your-node form was taken from ./src/client/components/your-node.vue
Client and Server debug is still working as before with source maps available.
And since we are using Vue for authoring forms, Vue dev tools are available in the browser and in VSCode.
disclaimer: AI is being used only to assist me with work that I've done thousand times. The whole framework design and implementation was conceived by my brain and hands. I started thinking about it around 2023~2024 after disliking my dev experience using vanilla Node-RED. I'm a believer that if Node-RED wants to standout dx is a must.
