Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
alxshine opened this issue Sep 20, 2024 · 1 comment

Comments

@alxshine
Copy link

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

@jvdprng
Copy link
Member

jvdprng commented Sep 23, 2024

Hi Alex,

I have a PR #48 that adds support for multi-root workspaces. Would it be possible in your example to open the Rust root and Go root as workspace roots (and not the parent directory)? In that case my PR might solve your issues (please check it out!). If there is a specific reason why the parent directory also needs to be open in the workspace, please let me know and I'll think whether this can be handled.

Cheers,
Joop

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants