Thanks @robertbrignull, I updated with the suggested name and included a line in the changelog. Let me know if you have any other feedback.

Regarding this line in the "Checklist", I'm not sure what needs to be done:

Issues have been created for any UI or other user-facing changes made by this pull request.

Thanks for adding a changelog entry.

Regarding this line in the "Checklist", I'm not sure what needs to be done:

Issues have been created for any UI or other user-facing changes made by this pull request.

Don't worry about that. You can ignore it, and we will tidy up the PR template.

Ping @robertbrignull. Anything else you need from me?

I'm very sorry for the delay. We have now discussed this internally. Unfortunately we're not sure we want to go this route because the implementation looks more complicated than initially thought.

We don't always use getOnDiskWorkspaceFoldersObjects when dealing with workspace folders. It's a good helper method but there are a large number of places where we access workspace.workspaceFolders directly, including modifying it, and often needing the exact index of a certain element.

As well as the implementation cost it's also not fully clear if this config option is what we will want long term. Is it the right level of granularity or should it apply to things other than workspace folders? Unfortunately it would be hard to change later without breaking user's workspaces.

Overall we might have to ask you to keep using your workaround for now. If this continues to be a problem or if there are other users experiencing the same issue, we can revisit this.

Thanks for the response. I think your concerns are reasonable. That being said, I'm wondering if there's any path forward for this by just focusing on codeql resolve library-path, which is the main source of the performance issues. Essentially, instead of modifying the global getOnDiskWorkspaceFoldersObjects, we just prevent certain folders from being added to --additional-packs when this resolve command is about to be executed. By scoping it down like this, we address the main issue without affecting other unrelated parts of the extension, and we make the setting name and description clear about exactly it applies to. If in the future we want to expand this to other parts of the extension, at least it wouldn't be a breaking change.

Overall we might have to ask you to keep using your workaround for now.

Funnily enough, the workaround started causing issues this morning. I think after I updated to 2.17.4, codeql complains when it sees an empty workspace file ([ERROR] resolve library-path> ERROR: File is empty.). I fixed it by changing the empty workspace file to just provides:, but this is an example of why relying on unofficially supported workarounds like this long-term is not a great idea. I also need to go make sure my colleagues are aware of this change now, as they don't really know any of the internals of how workspaces work or library paths are resolved, and would likely spend more time debugging this on their own.