I've been trying to checkout this branch so I can run it, but haven't been having much luck for the past couple of days

When you get time, do not forget to run npm run postinstall after npm install. :-) Also, I recommend nuking node_modules first.

I will! For now my issue is that git can't find the branch... (I've tried a few ways, the first being the commandline instructions at the bottom)

Oh that's weird. I can usually do a git fetch --all and then checkout other folks' branches.

Aha! The --all found it. None of adding you as a remote, cloning the fork as a separate repo, using GitHub's strange PR ID system worked...

I'm far from a Git guru but I use --all because I have the repo forked and this will fetch from both origin and what I call upstream (PowerShell/vscode-powershell). By default, a get fetch/pull only gets updates from origin which is typically your fork - again if you have forked the repo.

Yeah, I mean I'm on a fork, but I followed a StackOverflow post to add your fork as another remote (called rkeithhill) and ran git fetch rkeithhill. Couldn't work out why that didn't work. But anyway, resolved now!

Anyone hit anything similar to this:

Version 2.9.1
node_modules/vscode-languageclient/lib/client.d.ts:1:680 - error TS2305: Module ''vscode'' has no exported member 'CodeAction'.
1 import { TextDocumentChangeEvent, TextDocument, Disposable, OutputChannel, FileSystemWatcher as VFileSystemWatcher, DiagnosticCollection, Diagnostic as VDiagnostic, Uri, ProviderResult, CancellationToken, Position as VPosition, Location as VLocation, Range as VRange, CompletionItem as VCompletionItem, CompletionList as VCompletionList, SignatureHelp as VSignatureHelp, Definition as VDefinition, DocumentHighlight as VDocumentHighlight, SymbolInformation as VSymbolInformation, CodeActionContext as VCodeActionContext, Command as VCommand, CodeLens as VCodeLens, FormattingOptions as VFormattingOptions, TextEdit as VTextEdit, WorkspaceEdit as VWorkspaceEdit, Hover as VHover, CodeAction as VCodeAction, DocumentLink as VDocumentLink, TextDocumentWillSaveEvent, WorkspaceFolder as VWorkspaceFolder, CompletionContext as VCompletionContext } from 'vscode';
 ~~~~~~~~~~
node_modules/vscode-languageclient/lib/protocolConverter.d.ts:58:45 - error TS2694: Namespace ''vscode'' has no exported member 'CodeAction'.
58 asCodeAction(item: ls.CodeAction): code.CodeAction;
 ~~~~~~~~~~
node_modules/vscode-languageclient/lib/protocolConverter.d.ts:60:64 - error TS2694: Namespace ''vscode'' has no exported member 'CodeAction'.
60 asCodeAction(item: ls.CodeAction | undefined | null): code.CodeAction | undefined;
 ~~~~~~~~~~

I got similar errors when I did not execute npm run postinstall before I tried to compile with npm run compile.

Just ran it again and made sure I ran npm run postinstall. What's the sequence of commands I should be using?

My sequence for such an update is:

ri node_modules -r -for
npm install
npm run postinstall
npm run compile

After that, you can use ctrl+shift+b to compile

Okie doke -- I think I ran npm install the first time and it changed package.json. I reset to HEAD and ran the steps and it works very nicely.

Yeah, I had started this almost a month ago thinking - should be easy - and ran into the TextEdit multiple definition mess. I messed around with it on/off for a while and tabled it. Started up again played around with minimizing the number of npm pkg updates. That's when I noticed simply moving from TS 2.3.x to 2.4.x surfaced this error message.

It seems to me there is one def of TextEdit (and friends) you get with the vscode pkg and a slightly different TextEdit you get with vscode-languageclient. It wasn't until I went to TS 2.9.x that I noticed the code-fix light-bulb, invoked it and voila - compiler error went away.

I'm still frankly puzzled by the error. The best I can figure is that the use of DocumentRangeFormattingRequest.type (brings in TextEdit def from vscode-languageclient) in the same method that uses vscode's TextEdit causes the problem. But I wouldn't bet 2ドル on it. :-)

Yeah I'm imagining they've done something strange like defined a type twice and now there some version-dependent cross pollution that really isn't helped at all by the whole node_modules and node dependency management phenomenon. But unless it causes us any real problems, it doesn't feel worth trying to tackle.