Add COBOL Language Support

It would be very valuable to add support for COBOL source code to Graphify, enabling analysis and graph generation for legacy enterprise systems.

Motivation:
COBOL is still widely used in banking, insurance, and government systems. Many organizations are actively trying to understand and modernize large COBOL codebases, and Graphify could be a powerful tool for:

Visualizing program dependencies
Understanding call relationships ("CALL", "PERFORM")
Mapping copybook usage ("COPY")
Supporting modernization and migration efforts

Proposed Approach:
Graphify already has a clean architecture for adding new languages via tree-sitter, so COBOL support could follow the same pattern:

1.Add COBOL Parser

Integrate a tree-sitter grammar such as "tree-sitter-cobol"
Ensure compatibility with COBOL85 (initially?)

2.Add File Extensions
Update detection and watch logic to include:

".cob"
".cbl"
".cpy" (copybooks)
optionally ".cobol"

3.Implement LanguageConfig
Define a COBOL-specific "LanguageConfig" in "extract.py", including:

node types for programs, sections, paragraphs
call expressions
copy/include handling

4.Map COBOL Constructs to Graph Model
Suggested mappings:

"PROGRAM-ID" / "FUNCTION-ID" → top-level nodes
"SECTION" / "PARAGRAPH" → callable units
"CALL "program"" → "calls" edges
"PERFORM paragraph" → internal call edges
"COPY copybook" → "imports" / "includes" edges

5.Handle COBOL-Specific Nuances

Fixed vs free format source
Copybooks ("COPY" statements)
External vs internal calls
Dialect differences (start with COBOL85)

6.Tests (optional)

Add fixtures under "tests/fixtures/"
Validate node extraction and relationships in "tests/test_languages.py"

Benefits

Expands Graphify into legacy system analysis
Enables use in modernization workflows

Open Questions

How should data divisions / record structures be represented (or maybe not at all)?
Should copybooks be treated as imports or separate node types?

The proposal is well thought out and COBOL would be a genuinely useful addition given how many legacy modernization projects are out there.

One thing to check before starting: tree-sitter-cobol does not appear to be published on PyPI yet. All the other languages graphify supports use PyPI-published tree-sitter bindings so the PR would need to either find a published package or ship the grammar bindings. Worth confirming that exists and works before writing the extractor.

On your open questions:

Data divisions and record structures — skip them for now. The graph value is in understanding program flow and dependencies, not data layout. PROGRAM-ID, SECTIONs, PARAGRAPHs, CALL, PERFORM, and COPY already give you that. Record structures can always be added later.

Copybooks — treat them as imports. A COPY mybook is conceptually the same as an import in any other language. The copybook file becomes a node and the COPY statement becomes an imports_from edge pointing to it. That fits naturally into the existing graph model.

If you find a working PyPI package, happy to review a PR following the same pattern as the other language extractors in extract.py.

COBOL support is on our radar — the extractor design is solid (PROGRAM-ID, SECTIONs, PARAGRAPHs, CALL, PERFORM, COPY as imports). The blocker is tree-sitter-cobol not being available on PyPI — all graphify language bindings must be pip-installable. Will add it as soon as a published package exists.

@safishamsi

Hi @safishamsi ,
we'd need this as well
You are talking about this one that needs to be added to pypi, right?
https://github.com/yutaro-sakamoto/tree-sitter-cobol

Did add the support, can you confirm and let me know!

@safishamsi

Ah, it's already added?
Great, thank you very much!

We'll try it out and let you know, thanks a lot @safishamsi !

Yeah but our main platform app.graphify.com has everything

@safishamsi

Hi @safishamsi ,
we installed graphify locally and tried it out, it doesn't seem to support COBOL.
Did I misunderstand you earlier and you meant that only the app.graphify.com supports COBOL?
Thanks a lot!
Best regards

I can't see COBOL support in the current codebase, eg:

graphify/graphify/detect.py

Line 45 in b2cd362

    
           CODE_EXTENSIONS = {'.py', '.ts', '.tsx', '.mts', '.cts', '.js', '.jsx', '.mjs', '.cjs', '.ejs', '.ets', '.go', '.rs', '.java', '.groovy', '.gradle', '.cpp', '.cc', '.cxx', '.c', '.h', '.hpp', '.cu', '.cuh', '.metal', '.rb', '.rake', '.swift', '.kt', '.kts', '.cs', '.scala', '.php', '.lua', '.luau', '.toc', '.zig', '.ps1', '.psm1', '.psd1', '.ex', '.exs', '.m', '.mm', '.ml', '.mli', '.jl', '.vue', '.svelte', '.astro', '.dart', '.v', '.sv', '.svh', '.sql', '.r', '.f', '.F', '.f90', '.F90', '.f95', '.F95', '.f03', '.F03', '.f08', '.F08', '.pas', '.pp', '.dpr', '.dpk', '.lpr', '.inc', '.dfm', '.lfm', '.lpk', '.sh', '.bash', '.json', '.tf', '.tfvars', '.hcl', '.dm', '.dme', '.dmi', '.dmm', '.dmf', '.sln', '.slnx', '.csproj', '.fsproj', '.vbproj', '.xaml', '.razor', '.cshtml', '.cls', '.trigger', '.lisp', '.cl', '.lsp', '.asd'}

has no *.cob or *.cbl file types.

I also tried the v0.9.48 release to be sure

Is this a feature we can expect in the near future? Thanks, Donta

Navigation Menu

Repository navigation

Add COBOL Language Support #17

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Add COBOL Language Support #17

Description

Activity

safishamsi commented on Apr 7, 2026

safishamsi commented on Apr 8, 2026

paolovic commented on Aug 18, 2026

safishamsi commented on Aug 18, 2026

paolovic commented on Aug 18, 2026

safishamsi commented on Aug 18, 2026

paolovic commented on Aug 21, 2026

timohear-vector8 commented on Aug 21, 2026

donta-dalpoas commented on Sep 3, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions