fix(vscode): drop the contradictory compiler-not-found popup - #11527
fix(vscode): drop the contradictory compiler-not-found popup#11527Hamza Shah (Hamjaster) wants to merge 1 commit into
Conversation
When neither node nor tsp is on PATH, the server resolver shows a specific,
actionable popup ("compiler was found at X, but it cannot be started because
neither 'node' nor 'tsp' is available in PATH", with nvm/fnm/volta guidance) and
then still returns a tsp command as a last resort.
That spawn then fails with ENOENT, and the start handler reports a generic
"TypeSpec server executable was not found: 'tsp' is not found". So the user gets
two popups that disagree: one says the compiler was found, the other says it
was not.
Keep the generic message in the output channel but stop popping it up when the
resolver has already given the specific diagnosis. The last-resort spawn is
unchanged, so environments where `which` fails but the shell still resolves the
command keep working.
This does not remove the third popup in the report. That one ("client: couldn't
create connection to server ... spawn tsp ENOENT") comes from
vscode-languageclient, which calls error(..., 'force') and so bypasses
revealOutputChannelOn. Suppressing it would mean overriding the client's error
method or not attempting the doomed spawn at all; both are judgement calls for
maintainers rather than part of this fix.
|
Azure Pipelines: Successfully started running 1 pipeline(s). 1 pipeline(s) were filtered out due to trigger conditions. There may be pipelines that require an authorized user to comment /azp run to run. |
|
Hamza Shah (@Hamjaster) please read the following Contributor License Agreement(CLA). If you agree with the CLA, please reply with the following information.
Contributor License AgreementContribution License AgreementThis Contribution License Agreement (“Agreement”) is agreed to by the party signing below (“You”),
|
There was a problem hiding this comment.
Hi Hamza Shah (@Hamjaster), thanks for the contribution this is however not I think the right way to handle this, setting some global state like that is not very clean and this only solve 1 message. I think here we need to detach resolving the inputs and then have a single place reporting the issue at the end
Fixes #11343
The problem in plain terms
When the TypeSpec extension can't start its language server, it throws three error popups at you at once. They stack up and cover a good chunk of the screen.
Worse, two of them say opposite things. From the screenshot in the issue:
So one popup says it couldn't find the compiler, and another says it found it and tells you the actual reason it won't start. Popup 3 is the correct one, and it's the only one with useful advice (this is the classic nvm/fnm/volta situation where VS Code doesn't inherit your shell's PATH).
Why all three appear
The resolver figures out the real problem, shows popup 3, and then still hands back a
tspcommand anyway as a last resort, with a comment explaining that it might work in environments where the lookup fails but the shell can still find the command.That last-resort attempt then fails with
spawn tsp ENOENT, which produces the other two popups: one fromvscode-languageclientitself, and the generic "was not found" one from our own start handler.What this changes
The generic "was not found" popup no longer appears when the resolver has already given the specific diagnosis. It still goes to the TypeSpec output channel, so nothing is lost from the logs; it just stops competing with the accurate message.
Result: two popups instead of three, and the contradiction is gone. The one you're left with is the one that actually tells you what to do.
The last-resort spawn is untouched, so anyone currently relying on it keeps working.
Being upfront: this doesn't get you to one popup
The third popup ("client: couldn't create connection to server ... spawn tsp ENOENT") comes from
vscode-languageclient, not from this repo. It callserror(..., 'force')internally, and'force'deliberately bypasses therevealOutputChannelOnsetting we'd normally use to quiet it. I confirmed that in the installed library.Getting down to a single popup needs one of two decisions that felt like yours to make rather than mine:
undefinedso the client never starts. Cleanest result, one popup. But it removes the deliberate fallback, so anyone in the "lookup fails, shell works" case would break.errormethod in aLanguageClientsubclass to swallow that specific message. Keeps the fallback, but reaches into library behaviour.Worth noting that today's code shows the scary popup even when the fallback succeeds, which is arguably its own small bug. Happy to follow up with either option if you tell me which direction you prefer.
How I checked it
I couldn't reproduce the original conditions here (it needs macOS VS Code launched with a PATH that's missing node), so I want to be clear that this is verified by reading the flow plus type checking, not by watching the popups disappear.
What I did run, in
packages/typespec-vscode:tsc --noEmit: 28 errors before my change, 28 after, and none of them in the two files I touched. The pre-existing ones are all "Cannot find module '@typespec/compiler'" from workspace packages that aren't built in my sparse checkout.vitest run test/unit/task-command.test.ts: 4 passed. I couldn't add a unit test for this path because it needs the VS Code extension host and a broken PATH; the siblingextension.test.tsdoesn't even run without a built compiler. If there's a harness for this I missed, point me at it and I'll add one.prettier-plugin-typespecplugin since it isn't built in my checkout).To confirm by hand: launch VS Code so that
nodeisn't on its PATH (e.g. install Node via nvm and open VS Code from Finder rather than from a terminal) and open a.tspfile. Before, three popups; after, two, and neither claims the compiler is missing.An AI coding agent helped me write this. I reviewed the change, read the screenshot in the issue to identify each popup's source, and ran the checks above myself.