Allow Code Lenses to only Provide a Title and no Backing Command

[mjbvz]

Fixes #24209

Bug
Currently, for the js/ts references code lens, even if there are zero references you can click on the lens. This display an empty peek view. The root cause is that we always have to provide a command for these lenses, even if no action can really be taken

Fix
Allow code lenses to only register a title for the lens with no actual backing command. This lets a code lens display info to the user while not potentially incorrectly suggesting that more information is available by clicking

[mention-bot]

@mjbvz, thanks for your PR! By analyzing the history of the files in this pull request, we identified @jrieken and @egamma to be potential reviewers.

[mjbvz]

@jrieken I'm not a huge fan of this API design. Let me know if you have any suggestions on a better way to express this

[jrieken]

A command is not a string, the Command | string signature is a no-go

[jrieken]

Instead of these changes, a simple fix for #24209 could be to use a no-op command that does nothing

[jrieken]

The code-lens code is ready for this which makes this somewhat a problem with strict null and our command signature

if (command.id) {
	part = format('<a id={0}>{1}</a>', i, title);
	this._commands[i] = command;
} else {
	part = format('<span>{0}</span>', title);
}

[mjbvz]

@jrieken The problem with using a noop command is that it still renders the lens as a clickable element.

I was also hesitant to update the Command interface itself to make the command element nullable since that interface is used in so many other places. Perhaps we could instead take an empty string to mean that there is no command in this case? Other options:

• Change the signature to sometime like: command?: Command | {title: string}
• Add a new title field on the CodeLens

None of these seem great

[jrieken]

I'll check but #24469 (comment) tells me that we have been using undefined as the actual command already before. This became only visible with the strictNull-move. The empty string tricks sounds also like a valid workaround but in general receivers of Command must always validate it

[mjbvz]

Ok, I've switched to using an empty string for the case when there is no command. This works with the existing api and minimizes the number of changes we need to make