Skip to content

Request for feature feedback: Support for weaudit files in subdirectories #55

@alxshine

Description

@alxshine

Hello hello :)

Due to organizational reasons we usually have the code under audit as part of a larger repository which also contains our organizational stuff.
VSCode's language servers tend to behave badly when not opening the root of the source code project. E.g., if we're auditing Go code in one subdirectory, and Rust code in another, opening the project root in VSCode results in language support for neither.

What works is opening the subdirectory, and doing the auditing there.
Unfortunately, that means a lot of switching around repositories when moving the issues to the final report.

As a solution, I've modified the plugin to search subdirectories for all .weaudit files.
Paths in the .weaudit files have the location of the subdirectory (parent of the vscode where the .weaudit resides) prepended, to ensure that all code locations work correctly.
A preview of what it looks like in the file selector is attached, the findings are simply all findings merged.
image

The downside of this approach is that because loading weaudit files now uses vscode.workspace.findFiles, which caused me to make many of the functions asynchronous.
This also delays delays the tree viewer decorations a bit more at startup.

Would this be an interesting feature to you? Is the asynchronicity a dealbreaker?

I'm the tooling guy in our small team, and with how much we use your awesome plugin it would be cool if I could move my features upstream 😊

Thx much and have a nice day, Alex

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