Skip to content

Feature Request: Add support for Scala #105

Description

@mageshwaranr

Hi there! First of all, thank you for building such a great tool. My team and I currently use it for our Java, JS, Python, and Ruby services, and we really love it.

We were wondering if there are any plans to add support for Scala? Since AST Tree-sitter already supports Scala, we're hoping it might be a feasible addition.

Adding Scala support would be absolutely amazing for our workflow. Thanks again for your time and hard work on this project!

Activity

  1. anhnh2002 commented on Sep 10, 2026

    @anhnh2002
    Collaborator

    Hi @mageshwaranr, thanks a lot for the kind words and for the suggestion! Really glad to hear CodeWiki is working well across your Java, JS, Python, and Ruby services.

    Scala support makes total sense, so the groundwork is there. We don't have it on our immediate roadmap, but we'd be very happy to accept a contribution if you or your team are up for it. Kotlin was added by a community contributor following the same approach, so there's a good precedent.

    If you'd like to take a shot at it, the pieces to touch are:

    • Add a new analyzer at codewiki/src/be/dependency_analyzer/analyzers/scala.py. The Kotlin and Java analyzers are the closest references since Scala shares the JVM/package model.
    • Register the .scala extension in utils/patterns.py, ast_parser.py, analysis/call_graph_analyzer.py, analyzers/artifact.py, and prompt_template.py (grep for .kt and you'll find every spot).
    • Add the tree-sitter-scala dependency in pyproject.toml.
    • Add a small test like tests/test_ruby_analyzer.py with a sample Scala snippet.

    Happy to review and help out along the way, and feel free to ask here if anything in the analyzer structure is unclear. Thanks again!

  2. mageshwaranr commented on Sep 11, 2026

    @mageshwaranr
    ContributorAuthor

    Thanks @anhnh2002

    I'm still getting up to speed on the codebase, but I used AI assistance to dig into the requirements and lay out an initial plan.
    Check out the findings below—if you agree with this approach, I'm ready to open a PR to start implementing it. Let me know!

    proposal.md
    design.md

  3. anhnh2002 commented on Sep 14, 2026

    @anhnh2002
    Collaborator

    Hi @mageshwaranr, thanks for putting this together. This is a very thorough scoping pass, and I checked the main claims against the code: the whitelist gate in analysis_service.py, the commented-out dispatch warning, the OOP_TYPES set, and the dead _determine_component_type all check out. Yes, please go ahead and open a PR.

    Open questions: keep v1 tight. Skip given, extension, and type aliases entirely rather than mis-mapping them. Classes, case classes, traits, objects, Scala 3 enums, methods, and top-level defs are plenty for a first cut. Follow-ups are welcome once we see real output.

    Looking forward to the PR, and happy to answer questions along the way.

  4. mageshwaranr commented on Sep 14, 2026

    @mageshwaranr
    ContributorAuthor

    Raised #108

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions