Test VS Code API coverage against Theia for any VS Code extension

You can run it locally to see which APIs and commands are used. Whether they are declared already or missing. For dynamics commands it points you to code which should be analyzed. If you see some false positive please report issues.

[original thread by Anton Kosyakov]

[Kavith Thiranga Lokuhewage]

This seems a very useful tool. Just ran it for our VSCode extension and found that following three commands are missing.
“workbench.action.focusPreviousGroup”,
“workbench.action.openGlobalSettings”,
“workbench.action.reloadWindow”

File an issue in Theia repo if possible with a reference to your VS Code extnension. Alos you are welcome to fix it as usual :slight_smile:

[Ryan Dunn]

I am trying this with Live Share (out of curiosity). I have extracted the files from the .vsix, but I don’t see any extension.ts or main entry point for it. How would you use it here? https://marketplace.visualstudio.com/items?itemName=MS-vsliveshare.vsliveshare

[dehru]

I had ran from the source ( not the vsix ) file. I use a different entry point.

npx theia-vscodecov --main=src/index.ts

[dehru]

@anton-kosyakov Thanks for this tool!

Does this mean that my only issue in my extension is the built-in vscode.openFolder command is currently not supported in theia?

“missingSymbols”: [],
“missingCommands”: [
“vscode.openFolder”
],

[dehru]

OK, i see your tracking issue here:

[Kavith Thiranga Lokuhewage]

@anton-kosyakov sure will do and give it a try!

@dunnry it runs type analysis on sources. What you can try is to unpack live share vsix and check how generated js looks. If it is no minified and obfuscated and does not have dynamic requries you could have a chance to run it by creating tsconfig with allowJs enabled.

@dehru it means that APis which are used are declared in theia.d.ts. Usually if something is declared it is implemented as well. If an implementation is correct then yes only vscode.openFolder command is missing.

You can also see used APis and commands to get an idea what should be tested.

@anton-kosyakov when running the tool agains redhat-java, I get dynamic command calls like this:

“Commands.EXECUTE_WORKSPACE_COMMAND (/home/thomas/chedev/vscode-java/src/buildpath.ts 23:58)”,

where Commands.EXECUTE_WORKSPACE_COMMAND is a string constant. Would it be possible to resolve these before outputting them?

(in this case, it’s ‘java.execute.workspaceCommand’)

To folks at large: would it make sense to publish the result of running those tests somewhere? I’m going to run them against a bunch of extensions we are using in Che and I think it might be handy to have those results somehwere

If yes, can someone suggest a location? In an issue? Wiki?, etc?

I have not looked deeper, sometimes compilers provide APIs to resolve a value staticly if it is possible. If ts has such API it would be trivial to accomplish, if not we could do it ourself to some extent. You can file an issue i can have a look later, not this week :frowning:

I only use this tool as a starting point and read code for dynamic commands afterwards.

java.execute.workspaceCommand - it would be also good to pick up command ids from package.json to filter out commands contributed by an extension from VS Code commands

would it make sense to publish the result of running those tests somewhere? I’m going to run them against a bunch of extensions we are using in Che and I think it might be handy to have those results somehwere