Feature request: Support HTML/Jinja2 templates for FastAPI server-side rendered apps

[young-tim]

Feature request: Support HTML/Jinja2 templates for FastAPI server-side rendered apps

Hi, thanks for building CodeGraph. I have been using it on a Python/FastAPI project and noticed that server-side rendered frontend files are currently not indexed.

Current behavior

In a FastAPI + Jinja2 project, CodeGraph indexes the Python files and JavaScript static files, but skips HTML/Jinja2 templates.

Example project structure:

src/app/web/
├── app.py
├── static/
│   ├── js/
│   │   ├── navbar.js
│   │   └── utils.js
│   └── css/
│       └── style.css
└── templates/
    ├── products.html
    ├── monitor.html
    └── templates.html

Current CodeGraph result:

• app.py is indexed
• static/js/*.js files are indexed
• templates/*.html files are not indexed
• static/css/*.css files are not indexed

From reading the source, it looks like this is because .html, .htm, .jinja, .jinja2, and .j2 are not included in EXTENSION_MAP, so they are filtered out by isSourceFile() before indexing.

Why this matters

FastAPI projects often use Jinja2 for server-side rendering:

from fastapi.templating import Jinja2Templates

templates = Jinja2Templates(directory="templates")

@app.get("/monitor")
async def monitor_page(request: Request):
    return templates.TemplateResponse("monitor.html", {"request": request})

In this setup, an important part of the application flow is:

FastAPI route handler
  -> TemplateResponse("monitor.html")
  -> Jinja2 template
  -> static JS/CSS assets

Currently CodeGraph can see the Python route handler, but it cannot see the template file or the relationship between the route and the rendered frontend.

Requested support

It would be very helpful if CodeGraph could support FastAPI/Jinja2 server-side rendered applications.

A minimal version could be:

1. Add file-level indexing for template extensions:

   • .html
   • .htm
   • .jinja
   • .jinja2
   • .j2

2. Optionally add file-level indexing for CSS:

   • .css

Even if no symbols are extracted initially, having these files appear in codegraph_files would already be useful.

A more complete version could include a FastAPI/Jinja2 resolver that detects:

1. Jinja2 template setup:

   templates = Jinja2Templates(directory="templates")

2. Template rendering calls:

   templates.TemplateResponse("monitor.html", context)

3. Edges from route handlers to rendered templates:

   monitor_page -> templates/monitor.html
   

4. Jinja2 template relationships:

   {% extends "base.html" %}
   {% include "navbar.html" %}

5. Static asset references from templates:

   <script src="{{ url_for('static', path='js/utils.js') }}"></script>
   <link rel="stylesheet" href="{{ url_for('static', path='css/style.css') }}">

Expected outcome

For a FastAPI + Jinja2 app, CodeGraph should ideally be able to answer questions like:

• Which route renders this template?
• Which template is returned by this FastAPI endpoint?
• Which static JS/CSS files are referenced by this template?
• What templates extend or include this template?
• What would be affected if I change a given template or static asset?

Possible implementation approach

A first incremental step might be to treat HTML/Jinja2 files similarly to how .twig files are currently handled: tracked at the file level, without symbol extraction.

Then a later enhancement could add framework-specific extraction for FastAPI/Jinja2 relationships.

Thanks again for the project. I think this would make CodeGraph much more useful for Python web apps that use traditional server-side rendering rather than SPA frameworks.