We launched our new version of ast-visualizer. Switching from utilizing the builtin python ast module to tree sitter will allow for easy integration of javascript and other languages.
This started out as a passion project so funnily enough our spaghetti code detector has quite some technical debt itself.
But I have a dev branch where I am trying to get tree-sitter to work. As its ecosystem is an absolute beast when it comes to the amount of languages it supports this would definetly be my preferred method over doing all the languages manually.
The main challenge is normalizing the Trees and making sure all nodes are in a comparable state when we visualize them. (otherwise vsiualizing multilingual Codebases would be a real Pain)
Currently aiming to make it work for react, especially spotting how components relate to each other would be extremly helpful when dealing with local vs global css conflicts and similar issues
A few technical details for those interested in the behind the scenes:
Why AST? -> Simple regex or string parsing fails as soon as you hit complex decorators or nested classes. By using Python’s native AST module, we can get an objective map of the logic flow that doesn't care about formatting or comments.
The Visualization Challenge-> Rendering a dependency graph for a repo with hundreds of files can quickly turn into a laggy hairball. We spent a lot of time tweaking the D3.js force-directed graph parameters to ensure that nodes self-organize in a way that highlights clusters rather than just creating a mess.
Why Server-side? -> We chose server-side processing to handle larger repositories without crashing the user's browser (Numpy, FastAPI etc.), but we've architected it to be non permanent. The code lives in RAM just long enough to be parsed into a JSON structure for the frontend, then it's gone.
Next steps: -> I’m looking into adding Javascript, html and css support to make debugging the frontend much easier.
Old Show HN post: https://news.ycombinator.com/item?id=46945343#46945443