going to try this out then
So, i implemented this approach, and received the error:
› Error: There was an error: Cannot find module 'n8n-workflow'
› Require stack:
› - /home/node/.n8n/custom/GenericFunctions.js
› - /home/node/.n8n/custom/Directus.node.js
› - /usr/local/lib/node_modules/n8n/dist/src/LoadNodesAndCredentials.js
› - /usr/local/lib/node_modules/n8n/dist/src/index.js
› - /usr/local/lib/node_modules/n8n/dist/commands/start.js
› - /usr/local/lib/node_modules/n8n/node_modules/@oclif/config/lib/plugin.js
› - /usr/local/lib/node_modules/n8n/node_modules/@oclif/config/lib/config.js
› - /usr/local/lib/node_modules/n8n/node_modules/@oclif/config/lib/index.js
› -
› /usr/local/lib/node_modules/n8n/node_modules/@oclif/command/lib/command.js
› - /usr/local/lib/node_modules/n8n/node_modules/@oclif/command/lib/index.js
› - /usr/local/lib/node_modules/n8n/bin/n8n
- first, as soon as i included the
methods
property and not theexecute
function, in the class declaration in the main node file, to define the dynamic load options. - and then, when i removed the
methods
property and included theexecute
function
Hey @jan , is there some other step that i’m missing, to ensure not getting these errors: Cannot find module 'n8n-workflow'
?
That is very strange. If I import n8n-workflow
it works fine. Can also not understand why you should get an import error when you add the methods property. Just try to add smaller parts. If the 'methods
property is the problem then just add one method at a time, if you found the method that causes problems then try to identify the line that is causing the problem (the exact line that makes it break, so with that line it breaks, without it, it works). Then paste that line here, we can then maybe make sense of it.
I tried this now:
methods = {
loadOptions: {
// Get all Collections
async getCollections(
this: ILoadOptionsFunctions
): Promise<INodePropertyOptions[]> {
try {
const returnData: INodePropertyOptions[] = [];
return returnData;
} catch (error) {
throw new NodeApiError(this.getNode(), error);
}
},
}
};
Even this gives the error.
That does then not make any sense. If I do exactly what you describe I get a totally different result/error.
So what I do is:
- Create a totally new node with
n8n-node-dev new
- Build the node with
n8n-node-dev build
→ works as expected: fine - Add the above
methods
options to the code - Build that node with
n8n-node-dev build
→ fails as expected with the following error:
Expected as those three do not get imported so can not find them - So then change the following import line from:
import { INodeExecutionData, INodeType, INodeTypeDescription } from 'n8n-workflow';
to:
import { ILoadOptionsFunctions, INodeExecutionData, INodePropertyOptions, INodeType, INodeTypeDescription, NodeApiError } from 'n8n-workflow';
- Build that node with
n8n-node-dev build
→ works totally fine
So do not understand right now why you would get a totally different result.
Ah wait, did some further testing. It is not failing on build, it is failing on start.
Indeed, i probably missed mentioning that in the beginning
Probably overlooked that as the thread is getting quite long and a lot of other stuff is happening inbetween. Will check out that issue.
Had now some time to look into it shortly. The problem is that it imports n8n-workflow
relative and in the .n8n/custom
folder that module does not exist. Before that was not a problem as it only used the interfaces but in your code, it uses let’s say “actual code” because of the NodeApiError
and does so not work anymore.
So without doing a deep dive and thinking about it a lot, I guess the following things would be the easiest:
- use the absolute path when importing the
n8n-workflow
module - instead of using
NodeApiError
use a regularError
. So in your case, you can remove the whole try … catch block. Does then not display the super pretty errors in the frontend but will generally still work totally fine
Until a more permanent resolution for custom nodes materialise, would you be able to tell me what the absolute path (for n8n-workflow
and n8n-core
) would be, to use in any docker-based, production n8n instance?
Also, out of curiosity, how do all the other nodes works, as they all seem to import the module in the same way?
For now, better use the other solution and throw a regular error.
The other nodes are part of node-package that has n8n-workflow
as a dependecny.
Thanks for all the debugging!
Using a regular error, for now.
Also, it seems that the situation is applicable to other types of errors as well, like NodeOperationError
.