[fix] resolve brightscript.bsdk correctly when .code-workspace is not at project root - #878
Open
addison-adler wants to merge 9 commits into
Open
Conversation
…at project root
VSCode's getConfiguration pre-resolves relative paths and variables like
${workspaceFolder} against the wrong base when the .code-workspace file is
not at the project root. Use inspect().workspaceValue to get the raw
unresolved string, then expand ${workspaceFolder} and ${workspaceFolder:name}
variables ourselves before passing to parseVersionInfo.
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
…ce files Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
addison-adler
commented
Aug 17, 2026
addison-adler
commented
Aug 17, 2026
Co-authored-by: Addison <152139745+addison-adler@users.noreply.github.com>
…ce loop The PR accidentally changed the per-folder config read to always fetch from vscode.workspace.workspaceFile instead of each workspaceFolder. This meant multi-folder workspaces never accumulated distinct bsdk values, so selectBrighterScriptVersion was never called.
…, add get() fallback
In the folderResults reduce loop, getWorkspaceBsdkInfo was incorrectly
called with vscode.workspace.workspaceFile (always the same global
URI) instead of the current workspaceFolder, so all folders got the
same — usually undefined — value and selectBrighterScriptVersion was
never reached.
Also extend getWorkspaceBsdkInfo to fall back to get() when
inspect().workspaceValue is not set: workspaceValue carries the raw
unresolved string from the .code-workspace file (needed for
${workspaceFolder} expansion), while per-folder settings have no
workspaceValue and must be read via get().
TwitchBronBron
requested changes
Aug 21, 2026
TwitchBronBron
left a comment
TwitchBronBron
left a comment
Member
There was a problem hiding this comment.
I like the ${workspaceFolder} and ${workspaceFolder:name} concept. But I think the current logic needs a little bit of refactoring to keep the logic a little easier to follow.
| if (this.workspaceConfigIncludesBsdkKey()) { | ||
| let result = this.parseVersionInfo( | ||
| util.getConfiguration('brightscript', vscode.workspace.workspaceFile).get<string>('bsdk')?.trim?.(), | ||
| this.getWorkspaceBsdkInfo(vscode.workspace.workspaceFile), |
Member
There was a problem hiding this comment.
Not a fan of mixing workspaceFile and per-folder logic into one function. Should be:
- collect each folder's settings value
- collect the code-workspace value
- if code-workspace value exists, use it; else fall back to folder values
Right now that's inter-mixed inside getWorkspaceBsdkInfo's folder loop, so it's blurry (and weird, because in this case I think every folder's value would be identical since we're defaulting to the code-workspace's value). I'd expect the .code-workspace handling to live as separate logic after the per-folder loop, not merged into it.
Something more like this:
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Context
getConfiguration(...).get('bsdk')pre-resolves relative paths and variables like${workspaceFolder}against the wrong base when the.code-workspacefile is not at the project root${workspaceFolder}/node_modules/brighterscriptgets resolved tonode_modules/brighterscriptLanguageServerManager.tsuses the workspace file as thecwdlocationnet result:
.code-workspacedoesn't work anywhere except for the project rootChanges
Updated behavior:
brightscript.bsdkstarts with${workspaceFolder}, resolve relative to the first workspace folder (same behavior as VSCode)brightscript.bsdkstarts with${workspaceFolder:name}, resolve relative to the named workspace folderHow I Tested
${workspaceFolder},${workspaceFolder}, and plain string pathTest plan
.code-workspacefile in a subdirectory (e.g..vscode/) with a relativebrightscript.bsdkpath — language server should resolve correctly${workspaceFolder:FolderName}/node_modules/brighterscript— should resolve to the named folder's path${env:MY_VAR}— should surface a clear error in the BrightScript output panel.code-workspacefile) — behavior unchanged