You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
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
The text was updated successfully, but these errors were encountered:
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.
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.
The downside of this approach is that because loading
weaudit
files now usesvscode.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
The text was updated successfully, but these errors were encountered: