disclaimer: since my english is poor, I asked chatgpt to rewrite my proposal. The arguments are the same.
Currently, a limitation exists within the Node-RED ecosystem where installing multiple packages that define nodes with identical type strings results in only one of the nodes being registered and recognized by the runtime. This creates a significant challenge, especially when different packages inadvertently define nodes using the same type, such as credentials.
When package authors control both conflicting packages, resolving such conflicts is relatively straightforward—they can manually namespace or prefix node types to prevent collisions. For example, in a scenario where two packages are installed—one for AWS integration and another for Salesforce—both may define a config node of type credentials. In this case, the developers can rename the types to aws-credentials and salesforce-credentials, respectively, thus avoiding conflicts during registration.
However, this solution becomes problematic for package consumers. Consumers who do not own or maintain the packages would need to clone or fork the source code, identify all occurrences of the node types, and manually update them across potentially many files. This process is error-prone, non-trivial, and unsuitable for users without programming experience. Furthermore, any update to the original packages would require repeating this cumbersome process, risking further breakage or incompatibility.
To address this issue in a more user-friendly and robust manner, a potential solution would involve enhancing the Node-RED runtime and editor SDKs to automatically namespace node types during registration. This could be achieved by prefixing node types with a deterministic hash derived from each package's package-lock.json. By doing so, collisions would be inherently avoided without requiring manual intervention, ensuring that multiple packages can coexist even if they define nodes with the same original type names. This approach maintains compatibility while improving the experience for both developers and end users.
