I also have this problem primarily with this extension https://marketplace.visualstudio.com/items?itemName=felipecaputo.git-project-manager

Where I would:

1. ctrl+shift+n
2. ctrl+alt+p to run the extension command

} else if ( extensions are still loading ) {
await them and re-execute the function

That we don't do and that's on purpose. Editor commands, esp. typing, is being dispatched the same way and we don't want to block typing by slow extension activations. Unlikely, that we are changing this in the near future

@jrieken If the issue with my original proposal is performance what about this:

• Extracting all contributed commands from each extension's package.json file
• Merging all these commands in a list of "soon-to-be-available" commands
• After an extension completes its activation process its commands are removed from said list

So that when a command is triggered:

• If it's on the list, wait asynchronously for the associated extension to activate and then trigger the command
• If it's not on the list, it's handled as usual

Performance-wise the parsing step should be pretty fast, and most importantly it can be cached, a re-parse is only really needed if an extension is updated/installed.

This still won't fix the problem for dynamically registered commands, but I don't see much that can be done about them.

There was a gap (the time the workbench comes up until the time extension's package.json finished getting scanned and processed) when commands contributed by extensions could trigger this error.

We changed the heuristic during this time to be:

• if the command is known in the registry (e.g. the type command dispatched by the editor), it will execute without waiting for the scanning of package.json...
• if the command is not known in the registry, it will block on scanning of package.json...

@alexandrudima I'm still getting this issue using the Insiders build (89b158e 2017-11-24T06:03:48.383Z), am I doing something wrong?

@fabiospampinato We need to ask the author of that extension to enrich the activation events of the extension from * to '*', 'onCommand:terminals.runTerminal'.

When pressing ctrl+alt+t, we resolve that keybinding to the command terminals.runTerminal.
We then dispatch the command and eventually block on the activation event onCommand:terminals.runTerminal. But there is no extension listening to that activation event, so we proceed to look for and fail to find it. We do not wait for all * extensions to finish activating before invoking commands.

@alexandrudima Thanks for the explanation.

I don't think this is a good enough solution though. By using * the extension should be loaded at startup, i.e. as soon as possible. I don't see way there should ever be the need to also provide a more specific activation event like onCommand:terminals.runTerminal as well.

Why is VSC looking for commands inside activationEvents instead of contributes.commands?
There there are the commands. In this particular case I don't see how adding them to activationEvents provides any information that's not already available.

I'm actually the author of that extension, and 19 others, and it bothers me that I have to update them because of this issue. There's no way those thousands of other extensions are going to get updated.

I agree with you. The root problem is that there are two kinds of commands getting invoked via the command service: built-in core commands and contributed extensions commands.

There is a third, more rare case, where a built-in command is overwritten by a contributed command (e.g. the vim extension overwrites the built-in type command).

Now, the problem is that when dispatching a command, the command service has an id and doesn't really know if that command is a built-in one or a contributed one. It should block on the extension host process for contributed commands and it should not for built-in commands. e.g. undo, typing, saving a file, etc. any data-loss related commands should work even if the extension host process refuses to start up, is crashed, spins at 100% CPU, etc.

We need to bring in more knowledge about the two distinct kinds of commands to the command service.

I think an easy (maybe temporary) fix for this might be to add the following logic to the bit of code that extracts activation events from an extension: if one of the activation events is *, automatically add onCommand:extension.commandId for each command defined under contributes.commands.

To verify:

• package.json:

{
    "publisher": "alex",
    "name": "34913",
    "version": "0.0.0",
    "engines": {
        "vscode": "^1.0.0"
    },
    "activationEvents": [
        "*"
    ],
    "main": "index.js"
}

• index.js:

const vscode = require('vscode');

exports.activate = function () {
	vscode.commands.registerCommand(`hello`, () => {
		console.log(`hello!`);
	});
}

*keybindings.json:

    {
        "key": "cmd+1",
        "command": "hello"
    }

Open VSCode and press cmd+1 very quickly. The console should print hello! and you should not get a command not found warning.