What am I missing?

[moltar]

I am not sure if I am doing something wrong, or not, but the TypeScript workflow output doesn't provide any type hints (IntelliSense) for anything.

What is the value of having TypeScript over JSON, if none of the nodes are typed? At this point it's just a giant, untyped objects.

How does one write it as code, if the interfaces are not known?

For example, the workflow node looks like this:

    DeleteComment = {
        method: 'DELETE',
        url: '={{ $json.body.comment.url }}',
        authentication: 'predefinedCredentialType',
        nodeCredentialType: 'githubApi',
        options: {},
    };

[zombierobo]

Maybe the point of converting to typescript just because LLMs are really effective on working with typescript when compared to json's.

Ideally I would want to improve the linkage between node referencing data from another nodes and catching run time errors at compile time that would make a lot of sense for having typescript notation. I often find myself referencing data in a node from another node up the workflow chain and if I delete or add another way of doing up the chain, the downstream is broken but can only be known during run time. Also ideally the jsCode in code node could be a proper js file with type checking and validations etc and possibility to add unit tests separately using jest.

Not related to this topic but i was looking at ways to run a unit test with mocked data from nodes and verifying workflow logic works as expected. Maybe with typescript representation, we could have a lightweight n8n workflow simulator that can run tests with mocked data ?

[EtienneLescot]

I am not sure if I am doing something wrong, or not, but the TypeScript workflow output doesn't provide any type hints (IntelliSense) for anything.

What is the value of having TypeScript over JSON, if none of the nodes are typed? At this point it's just a giant, untyped objects.

How does one write it as code, if the interfaces are not known?

For example, the workflow node looks like this:

    DeleteComment = {
        method: 'DELETE',
        url: '={{ $json.body.comment.url }}',
        authentication: 'predefinedCredentialType',
        nodeCredentialType: 'githubApi',
        options: {},
    };

@moltar You’re not missing anything.

And I think @zombierobo is pointing in the right direction: a big part of the value of the TypeScript format is that AI coding agents work much better with TypeScript than with large nested JSON blobs.

That said, the goal of .workflow.ts today is not “full static typing for every n8n node parameter”. It is mainly to provide a workflow representation that is:

• easier to read
• easier to review in Git
• easier to diff cleanly
• much easier for AI agents to generate and edit reliably

So if you expect deep IntelliSense for every node config, that is not really the promise today.

The hard part is that n8n nodes are very dynamic: available fields depend on resource/operation choices, and many expressions only make sense at runtime ($json, $node, etc.). Because of that, full compile-time typing is a much bigger problem than just switching from JSON to TypeScript syntax.

I do agree with the broader direction mentioned above though:

• better validation of cross-node references would be valuable
• catching more workflow wiring issues before runtime would be valuable
• a lightweight test/simulation approach with mocked node data would also be very interesting

So the short answer is: TypeScript is there first as a clearer, more elegant, Git-friendly, and AI-friendly representation of workflows, not yet as a fully typed n8n programming model.

The docs probably need to be clearer here: “TypeScript workflow format” should not be read as “every n8n node is already exposed as a perfectly typed TypeScript API”.

[moltar]

But how does the agent knows which props to use?

[EtienneLescot]

Not from the TypeScript syntax itself.

The .workflow.ts file is mostly the authoring format. The agent knows which props to use because n8n-as-code ships a local n8n ontology: node schemas, option values, docs, examples, validation, plus generated AGENTS.md instructions that tell the agent how to use the toolchain safely.

So the flow is:
ground the agent with AGENTS.md -> query n8nac for node info / docs / examples -> edit the workflow -> validate -> push.

In other words, TypeScript is the readable representation; the ontology and n8nac commands are what provide the actual knowledge of valid props.