Enhanced Workflow Data Readability when pushed to GIT with Multi-Line JSON Arrays or YAML Literal Style Support

Dear n8n Team,

I am writing to propose enhancements to the n8n workflow format that could significantly improve usability and readability, particularly when workflows are stored, reviewed, and managed through version control systems like GitHub. These improvements are aimed at making the workflow code easier to read and review, especially for complex workflows that need to be managed by larger teams and include custom scripts or extensive text blocks (for example in SQL nodes, etc).

1. Multi-Line JSON Arrays for Text and Code Blocks

Currently, when defining workflows in JSON format, text and code blocks must be represented as single-line strings, often including \n to denote line breaks. This format can be cumbersome and error-prone when reviewing complex scripts or lengthy text content. I propose an alternative where such content can be expressed as arrays of strings, with each array element representing a line of text or code.

Example:

{
  "type": "FunctionNode",
  "parameters": {
    "functionCode": [
      "const results = [];",
      "for (let i = 0; i < 5; i++) {",
      "  results.push({ value: i });",
      "}",
      "return results;"
    ]
  }
}

This representation would allow for each line of code to be distinctly visible and editable, enhancing clarity and making version control diffs cleaner and more meaningful.

2. Cleaner Option: YAML Format with Literal Style (Pipe Option) for Workflow Definitions

In addition to JSON, supporting YAML for workflow definitions could provide an even more readable format, especially using the literal style denoted by |. This style preserves new lines and indentation, making it ideal for embedding scripts, SQL queries, or extensive configuration data within workflows.

Example:

type: FunctionNode
parameters:
  functionCode: |
    const results = [];
    for (let i = 0; i < 5; i++) {
      results.push({ value: i });
    }
    return results;

The YAML literal style not only enhances readability but also aligns with common practices in software development, where YAML is widely used for configuration files.

Benefits:

Enhanced Readability: Both enhancements make the workflows easier to read and understand at a glance, which is crucial for new team members or external reviewers.

Simplified Version Control: Changes to workflows are easier to track and review in version control systems, promoting better collaboration and code quality.

Reduced Errors: More readable formats can help reduce errors in editing and updating workflows, as the structure and flow of the code or text are clearer.

We believe these enhancements will make n8n even more user-friendly and maintainable, especially for teams that manage complex workflows.

I think the n8n JSON file is not intended to be read by humans. It’s very complex and unreadable when there are a lot of nodes. Even a couple of Code nodes with a significant amount of code will be completely unreadable. And this is only about the nodes, the node linking is the next big topic :sweat_smile:

Instead, maybe it will be better to have something like a review mode in n8n. With workflow versioning and node/links highlighting when something has changed

Yeah, totally agree… having a review feature within N8N itself that highlights the nodes and code lines that have changed would be the ideal solution. My proposal was more of a stepping stone to the recently released “Push to Git” feature, to try to make it more manageable for teams (and humans in general) to review changes in a workflow holistically.