Change the custom node types

Hi,

I’m using version 1.16.0.
As I realized custom nodes always have a type of CUSTOM, like CUSTOM.testNode

How can I change this custom keyword?

Regards

It looks like your topic is missing some important information. Could you provide the following if applicable.

  • n8n version:
  • Database (default: SQLite):
  • n8n EXECUTIONS_PROCESS setting (default: own, main):
  • Running n8n via (Docker, npm, n8n cloud, desktop app):
  • Operating system:

Version 1.16.0
Database: postgres
own
npm
archlinux

Hey @jellybean,

What do you mean? Is this for nodes installed into the custom folder outside of the UI for community nodes?

1 Like

Yes, Nodes that installed into the “custom” folder.

Hey @jellybean,

Perfect, So we use the custom type to identity them internally. Is there any specific reason as to why you would want to change it?

I’m using n8n for about 2 years with bunch of custom nodes, I created a sub-package like nodes-base (I named it nodes-something) but it contains my custom nodes, Everything was fine until version 1.
n8n can’t recognize my custom nodes inside nodes-something sub-package anymore.
I copied them to custom directory, and everything seemed to be fine but the types.
Before that custom nodes have this type: n8n-nodes-something.testNode
But in custom directory, nodes have this type: CUSTOM.testNode
So n8n wouldn’t recognize any of my nodes inside workflows and executions.

Any idea?
@Jon

You can put them in 2 locations one will result in getting the ‘‘CUSTOM.’’ and the other ‘‘n8n-nodes-something’’

I am guessing the first is with the ‘‘CUSTOM’’
assuming you set this as the custom node location as well If I recall correctly
env variable: N8N_CUSTOM_EXTENSIONS

  1. /custom_nodes
  2. /home/node/.n8n/nodes
1 Like

This is it, Nodes under the custom directory are treated and labelled as custom so we can tell them apart from nodes under .n8n/nodes which are normally community nodes. I can’t see this really changing but maybe we need to update the v1 braking changes / migration guide to make this clearer.

1 Like

Thanks,
Maybe we could allow users to change this CUSTOM keyword via environment variable. What do you think?

Hey @jellybean,

I am not really sure what value that would actually add as in theory this is only an issue if you were using the older node paths :thinking:

Part of releasing v1 was to break a lot of stuff at once that we were not happy with so we can have an easier life in the future, I feel like the best solution would be to mention this in the docs.

1 Like

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.