Add a CSV node to parse and build CSV data

[asimodabas]

[Feature]: Add a CSV node to parse and build CSV data

Problem

Heym has data nodes for Google Sheets, Grist, DataTable, and BigQuery, but there is no simple, dependency-free way to work with raw CSV text inside a workflow. A very common need in data / AI pipelines is to:

• turn a CSV string (from an HTTP response, a file, an LLM output, etc.) into structured rows, or
• turn structured rows back into a CSV string (to send by email, upload, or return from a Portal / webhook).

Today this requires the Code node or manual expression logic, which is more effort than a dedicated node would be.

Proposal

Add a first-class CSV node (category: Data) with two operations:

• parse — CSV text → array of row objects (keyed by header) or array of arrays.
• build — array of row objects/arrays → CSV text.

The node needs no credentials — it is a pure in-memory transform, so it slots cleanly next to set, merge, and jsonOutputMapper.

Not already covered

CSV currently only exists as a file conversion / export format — e.g. the Google Drive node can convert a stored file to CSV (driveConvertTargetFormat: "csv"), and CSV is a recognized file/attachment type. There is no standalone, credential-free node that parses raw CSV text into rows or builds CSV text from rows inline in a workflow. This proposal is that missing transform node, not a change to the existing Drive conversion.

Proposed fields

parse:

• csvText (string, expression-capable) — the input CSV
• delimiter (string, default ,)
• hasHeader (boolean, default true) — first row is the header
• trimValues (boolean, default true)

build:

• rows (expression-capable) — array of objects or arrays
• delimiter (string, default ,)
• includeHeader (boolean, default true)
• columns (optional string list) — explicit column order

Example I/O

parse:

csvText: "name,age\nAda,36\nGrace,45"
->
{ "rows": [ { "name": "Ada", "age": "36" }, { "name": "Grace", "age": "45" } ] }

build:

rows: [ { "name": "Ada", "age": 36 }, { "name": "Grace", "age": 45 } ]
->
{ "csv": "name,age\nAda,36\nGrace,45" }

Affected areas

Backend:

• backend/app/services/node_execution/nodes/csv_node.py — new handler
• backend/app/services/node_execution/registry.py — register the handler
• backend/app/models/schemas.py — node/operation schema metadata
• backend/app/services/workflow_dsl_prompt.py — DSL fields, defaults, expression/autofill hints

Frontend:

• frontend/src/types/node.ts — node type registration
• frontend/src/components/Panels/propertiesPanel/nodes/CsvNodeProperties.vue — config UI
• frontend/src/lib/nodeIcons.ts — icon

Docs (per the node-integration policy):

• frontend/src/docs/content/nodes/csv-node.md
• frontend/src/docs/manifest.ts
• frontend/src/docs/content/reference/features.md and node-types.md

How to test

The feature can be verified at three levels so we can prove both correctness and no regression to existing flows.

1. Correctness — new node unit tests

Add backend/tests/test_csv_node.py (pure, deterministic — no external services), following the existing node-handler test style (unittest + a SimpleNamespace executor stub). Cases:

• parse with header → list of dicts keyed by header
• parse with hasHeader: false → list of lists
• quoted fields containing the delimiter, e.g. "Smith, Jr."
• fields containing embedded newlines inside quotes
• custom delimiter (e.g. ;), and trimValues on/off
• empty input → { "rows": [] }
• build from dicts with/without header, custom columns order
• build escaping: values containing the delimiter, quotes, or newlines are quoted correctly
• round-trip: build(parse(x)) == x for a representative sample

2. No regression — full backend suite + guard tests

Because the node is purely additive, every existing test must still pass unchanged. The repo already ships guard-style tests that catch cross-cutting breakage, e.g. backend/tests/test_workflow_json_compatibility.py (workflow JSON backward compatibility) and the DSL-prompt tests. Running the full backend suite should stay green.

3. UI — Playwright E2E

A spec mirroring the existing node-property specs (jira-node-properties.spec.ts, playwright-node-properties.spec.ts) can confirm the node is addable to the canvas, both operations render their fields, and expression-capable fields open the expression dialog.

The usual ./check.sh (lint + typecheck + backend tests) and the E2E PR job gate all of the above.

Alternatives considered

The Code node can parse/build CSV, but that requires writing Python per workflow and loses the visual, typed, expression-friendly experience. A dedicated node matches how Heym treats other data formats.

I'm happy to open a PR for this if it's welcome.

[ckakgun]

Hi @asimodabas ,

First of all, thank you for the thoughtful proposal and for offering to contribute 🤗 We agree that, even with our native AI workflow builder and expression generator, a dedicated converter would be a meaningful UX improvement. It would make common data transformations simpler and more accessible in visual workflows.
We’d be happy to accept your contribution. One request: rather than naming it a CSV node, please call it the Converter node. We prefer a broader, technology-neutral name because it leaves room for additional conversion formats and use cases beyond CSV.

Please follow the repository’s AGENTS.md and contribution guidelines when preparing the PR, including the required tests, UI coverage where practical, and documentation updates.
Feel free to proceed, and thank you again for your valuable contribution 🚀

[asimodabas]

"Converter" is an excellent call a technology-neutral name is the right design choice, since it leaves room to support additional formats later without reworking the node.

I'll start with CSV ↔ JSON as the first supported conversions and follow AGENTS.md end to end: backend handler and registration, the properties panel and node wiring on the frontend, backend unit tests plus Playwright coverage, and the documentation updates. The change is purely additive, so existing nodes remain untouched.

I'll open the PR once everything is green locally 🚀